Menu
▾
▴
#2208 segfault in __flush_mt() in some circumstances
The following crash can be obtained in two ways. First one is ~100% reproducible:
1. start sfcbd, during intialization of registered providers (interop in this case)
2. press CTRL-C
The second one is not always reproed and can be detected with use with my provider. But it seems that the path of error is somewhat similar.
I have tried to track the problem with valgrind, I will attach full log shortly, just a fragment here:
valgrind.log, lines 378-400:
==31805== Invalid read of size 4
==31805== at 0x4073660: __flush_mt (support.c:383)
==31805== by 0x40753F1: tool_mm_flush (support.c:620)
==31805== by 0x40975F2: processProviderInvocationRequestsThread (providerDrv.c:2722)
==31805== by 0x4097CFC: processProviderInvocationRequests (providerDrv.c:2814)
==31805== by 0x4098A74: forkProvider (providerDrv.c:649)
==31805== by 0x40870DA: lookupProviderList (providerMgr.c:381)
==31805== by 0x4087546: instProviderList (providerMgr.c:458)
==31805== by 0x4088BC5: processProviderMgrRequests (providerMgr.c:953)
==31805== by 0x804A7F7: main (sfcBroker.c:871)
==31805== Address 0x4766c90 is 4 bytes after a block of size 20 alloc'd
==31805== at 0x40277F1: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31805== by 0x41373B5: _dlerror_run (in /lib/libdl-2.11.3.so)
==31805== by 0x4136CA6: dlopen@@GLIBC_2.1 (in /lib/libdl-2.11.3.so)
==31805== by 0x4093863: loadProvider (providerDrv.c:2511)
==31805== by 0x40977CE: processProviderInvocationRequestsThread (providerDrv.c:2701)
==31805== by 0x4097CFC: processProviderInvocationRequests (providerDrv.c:2814)
==31805== by 0x4098A74: forkProvider (providerDrv.c:649)
==31805== by 0x40870DA: lookupProviderList (providerMgr.c:381)
==31805== by 0x4087546: instProviderList (providerMgr.c:458)
==31805== by 0x4088BC5: processProviderMgrRequests (providerMgr.c:953)
==31805== by 0x804A7F7: main (sfcBroker.c:871)
No more serious errors can be found in this log.
valgdrind full log
core dump
Yes, this is a known issue: attempting to shutdown sfcbd during startup makes for an unhappy end. We haven't seriously dug into this problem because it doesn't really affect any normal use cases. The only problem would be the generation of the core file; sfcbd does in fact still shut down completely. So for this reason, we haven't spent any time trying to fix it.
Are you seeing any other side effects besides the core file?
Setting to "pending". If no comment, this item will close in 60 days.