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@linux.vnet.ibm.com