Hide Forgot
Description of problem: This fault happens during an automated system test, soon after a client attempts to connect to the faulting broker. Attached is the core dump from qpidd. The dump shows the seg fault being triggered by calling Connection::Close, which is pure virtual when called. Version-Release number of selected component (if applicable): Amentra Hotfix 4, but the same behavior was seen in Hotfix 3 How reproducible: Very intermittent, only happens a couple of times a week. Additional info:
Created attachment 475096 [details] Core Dump of qpidd
I can't get backtraces from that core file on RHEL5.5 using the packages from https://brewweb.devel.redhat.com/buildinfo?buildID=154041. Can you confirm the rpms and platform details? Even better, can you attach the backtrace for all threads please?
Created attachment 475223 [details] Backtraces for all threads and rpm versions of source machine
Packages specifically for the rpms this core was generated with are available here: https://brewweb.devel.redhat.com/buildinfo?buildID=154016 However this issue will most likely also impact 1.3 general packages as none of the extra fixes are likely to cause this segfault.
Is this broker running clustered or standalone?
This broker is running standalone. I believe that the sum of all configuration applied to this broker is in the path reported by the core dump, the configuration file is not used for these tests.
Could you give some more details about what the test is doing? It looks like the crash happens when the client disconnects from a broker, but the original report says it happens shortly after _connecting_. Is the test a one where clients connect and disconnect repeatedly? If so are the disconnects abrupt or orderly?
This is a test where the client connects after a previous abrupt disconnect.
The crash happens in these lines of code in qpid::broker::Connection::closed() in qpid/broker/Connection.cpp: 294 while (!channels.empty()) >295 ptr_map_ptr(channels.begin())->handleDetach(); I think the intent here is to iterate over every channel and detach it, presumably a side effect of handleDetach() is to actually remove the channel from the channels map else the map would never end up empty. In the crashing case what happens is that the Session which is called into here seems to only be partially constructed and so not all of its virtual functions are there yet this causes the call of a non existent pure virtual function. Generally this happens if the object has already been deleted or in the process of being deleted in another thread when this code runs or even in the process of being created. Looking at then other threads the Session doesn't seem to be in the process of deletion.
If we are running the same automated test and we're not seeing this behaviour we should close the bug.
Multithreaded segmentation faults can be highly intermittent. We have not noticed a core recently that duplicates the issue. I would feel better about this defect being closed if there was some change since then that may have fixed it.
I agree with Chris.
This bug seems related to/or a duplicate of Bug 883469. Since we have not seen it for a long while I'm going to close it as a duplicate. *** This bug has been marked as a duplicate of bug 883469 ***