Bug 990240
| Summary: | segfault in qpidd if client attempts to transactionally dequeue the same message twice | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Gordon Sim <gsim> | ||||
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Leonid Zhaldybin <lzhaldyb> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 2.3 | CC: | esammons, jross, lzhaldyb, mcressma, pmoravec | ||||
| Target Milestone: | 2.3.6 | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | qpid-cpp-0.18-18 | Doc Type: | Bug Fix | ||||
| Doc Text: |
Cause:
In a transactional session, if a client accepts a message, the commits, then accepts the same message again, then commits again, the broker will crash
Consequence:
The broker will crash.
Fix:
The broker now ignores the extraneous accept.
Result:
The broker does not crash.
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 1048198 (view as bug list) | Environment: | |||||
| Last Closed: | 2013-11-22 00:43:45 UTC | Type: | Bug | ||||
| 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: | |||||||
| Bug Blocks: | 1026347, 1048198 | ||||||
| Attachments: |
|
||||||
Fixed upstream by https://svn.apache.org/r1508516 (which should port simply to 0.18 based tree as well) Patch backported to 0.18 and uploaded to https://issues.apache.org/jira/secure/attachment/12595451/QPID-5025-0.18.patch (a move of the curly bracket prevents patch applying the change from trunk cleanly) Tested on RHEL5.9 and RHEL6.4 (both i386 and x86_64). The reproducer script was running in a loop for longer than 24 hours without triggering the issue. This seems to be fixed. Packages used for testing: RHEL5.9 python-qpid-0.18-5.el5_9 python-qpid-qmf-0.18-18.el5_9 qpid-cpp-client-0.18-18.el5_9 qpid-cpp-client-devel-0.18-18.el5_9 qpid-cpp-client-devel-docs-0.18-18.el5_9 qpid-cpp-client-ssl-0.18-18.el5_9 qpid-cpp-server-0.18-18.el5_9 qpid-cpp-server-cluster-0.18-18.el5_9 qpid-cpp-server-devel-0.18-18.el5_9 qpid-cpp-server-ssl-0.18-18.el5_9 qpid-cpp-server-store-0.18-18.el5_9 qpid-cpp-server-xml-0.18-18.el5_9 qpid-java-client-0.18-8.el5_9 qpid-java-common-0.18-8.el5_9 qpid-java-example-0.18-8.el5_9 qpid-jca-0.18-8.el5 qpid-jca-xarecovery-0.18-8.el5 qpid-qmf-0.18-18.el5_9 qpid-tools-0.18-10.el5_9 RHEL6.4 python-qpid-0.18-5.el6_4 python-qpid-qmf-0.18-18.el6_4 qpid-cpp-client-0.18-18.el6 qpid-cpp-client-devel-0.18-18.el6 qpid-cpp-client-devel-docs-0.18-18.el6 qpid-cpp-client-ssl-0.18-18.el6 qpid-cpp-server-0.18-18.el6 qpid-cpp-server-cluster-0.18-18.el6 qpid-cpp-server-devel-0.18-18.el6 qpid-cpp-server-ssl-0.18-18.el6 qpid-cpp-server-store-0.18-18.el6 qpid-cpp-server-xml-0.18-18.el6 qpid-java-client-0.18-8.el6_4 qpid-java-common-0.18-8.el6_4 qpid-java-example-0.18-8.el6_4 qpid-jca-0.18-8.el6 qpid-jca-xarecovery-0.18-8.el6 qpid-qmf-0.18-18.el6_4 qpid-tools-0.18-10.el6_4 -> VERIFIED Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1755.html |
Created attachment 780732 [details] reproducer Description of problem: On a transactional session, a client accepts a given message then commits, then issues another accept for the same message and commits again. This results in a segfault on the broker (though it is an invalid sequence of requests the broker clearly should not crash). Version-Release number of selected component (if applicable): 2.3 How reproducible: 100% Steps to Reproduce: 1. run attached python script (uses old client API to do steps as described above) Actual results: Broker crashes with segfault Expected results: No crash, broker simply ignores the extraneous accept Additional info: