Bug 586348
Summary: | qpid c++ client library crash in qpid::loadModuleDir() / qpid::loadModuleDir()->::isShlibName() | ||
---|---|---|---|
Product: | Red Hat Enterprise MRG | Reporter: | Frantisek Reznicek <freznice> |
Component: | qpid-cpp | Assignee: | Andrew Stitcher <astitcher> |
Status: | CLOSED ERRATA | QA Contact: | Frantisek Reznicek <freznice> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | Development | CC: | esammons, gsim |
Target Milestone: | 1.3 | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-10-20 11:30:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 589675 | ||
Bug Blocks: |
Description
Frantisek Reznicek
2010-04-27 11:31:56 UTC
The issue here comes from linking in pthreads before qpidclient. If you compile the client with: g++ -Wall -g -I. -I/usr/include/qpid-boost bz452015.cpp -lqpidclient -o bz452015, then the above expectations are met. In fact even if the -lpthread is added in after the -lqpidclient then the issue is resolved. A similar issue can be seen if you link in pthread before any qpid client based executable (e.g. direct exchange example). Yes, indeed, the crash is caused by linking libpthread before libqpidclient. Clients behave correctly now. The cause of this crash is undefined initialisation order: LoadtimeInitialise() at qpid/client/LoadPlugins.cpp:47 which is part of a static global constructor and so is called before main(). It relies transitively on suffix in qpid/Modules.cpp:39 which is also a static global also constructed before main(). These things are in different files nad in fact in entirely different shared objects. Since c++ does not define the order of construction of static globals (except in the same file) under some circumstances the construction order may work because suffix gets constructed before LoadtimeInitialise(), and in others it may not thus causing this crash. This should now be fixed upstream at r938701 I fixed it with the "belt and braces" approach of making LoadtimeInitialise no longer run as part of a static global constructor and also making suffix accessed using a "static singleton" pattern. The issue has been fixed, tested on RHEL 4.8 / 5.5 i386 / x86_64 on packages: python-qmf-0.7.946106-7.el5 python-qpid-0.7.946106-9.el5 qmf-0.7.946106-10.el5 qmf-devel-0.7.946106-10.el5 qpid-cpp-client*-0.7.946106-10.el5 qpid-cpp-mrg-debuginfo-0.7.946106-8.el5 qpid-cpp-server*-0.7.946106-10.el5 qpid-java-*-0.7.946106-7.el5 qpid-tools-0.7.946106-7.el5 ruby-qmf-0.7.946106-10.el5 -> VERIFIED |