sfcb log says a sigsev:
-#- Virt_ComputerSystemIndicationProvider - 10624 provider exiting due
to a SIGSEGV signal
Debugging there, a backtrace shows me a null mi->ft in
stdi_enable_indications() yet same pointer in sfcb's stack is valid:
(gdb) bt
#0 stdi_enable_indications (mi=0xbfb3e778, ctx=0xb801f0b8) at
std_indication.c:270
#1 0xb7fc137c in enableIndications (hdr=0x80625c0, info=0x805b0d0,
requestor=-75) at providerDrv.c:2192
#2 0xb7fc2d80 in processProviderInvocationRequestsThread
(prms=0x805a8d0) at providerDrv.c:2585
#3 0xb7fc3514 in processProviderInvocationRequests (name=0x8050720
"Virt_ComputerSystemIndicationProvider") at providerDrv.c:2700
#4 0xb7fb523c in getProcess (info=0x80507a8, proc=0xbfb3ef14) at
providerDrv.c:602
#5 0xb7fb5709 in forkProvider (info=0x80507a8, req=0x805abb0, msg=0x0)
at providerDrv.c:653
#6 0xb7fadc9d in lookupProviderList (type=4, requestor=0xbfb3f018,
req=0x805abb0) at providerMgr.c:368
#7 0xb7fae3eb in processIndProviderList (requestor=0xbfb3f018,
req=0x805abb0) at providerMgr.c:449
#8 0xb7fb025e in processProviderMgrRequests () at providerMgr.c:857
#9 0x0804aa14 in main (argc=3, argv=0xbfb3f154) at sfcBroker.c:791
(gdb) p *mi
$5 = {hdl = 0x0, ft = 0x0}
(gdb) up
#1 0xb7fc137c in enableIndications (hdr=0x80625c0, info=0x805b0d0,
requestor=-75) at providerDrv.c:2192
2192 info->indicationMI->ft->enableIndications(info->indicationMI,ctx);
(gdb) p *(info->indicationMI)
$6 = {hdl = 0xb801f0a0, ft = 0xb801f180}
(gdb)
Yes, this is really odd. The info is correct in sfcb's stack:
(gdb) up
#1 0xb7ff437c in enableIndications (hdr=0x805f2b8, info=0x805a900,
requestor=-75) at providerDrv.c:2192
2192 info->indicationMI->ft->enableIndications(info->indicationMI,ctx);
(gdb) p *(info->indicationMI)
$4 = {hdl = 0xb80530a0, ft = 0xb8053180}
(gdb) p info->indicationMI->ft
$5 = (CMPIIndicationMIFT *) 0xb8053180
(gdb) p info->indicationMI->ft->miName
$6 = 0xb8050b44 "IndicationVirt_ComputerSystemIndicationProvider"
I put a break statement on the following line in libcmpiutil in
stdi_enable_indications():
_ctx = (struct std_indication_ctx *)mi->hdl;
The contents of mi were already blown at that point. We're not doing
any kind of manipulation on mi, so I suspect that sfcb is handing us a
bogus mi pointer. I'm not sure how that is happening though.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com