[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16256973#comment-16256973 ] Alan Conway commented on QPID-7991: --- The bug would not be triggered if all the detached bridges were already at the end of the vector; then std::remove_if wouldn't bother moving them, it would simply return an iterator to the dead zone and everything would work fine. Possibly your tool does things in a slightly different order or with different timing - so your tool causes mixed batches detached/active bridges to be processed, where python tool did not. E.g. (speculating) the python tool might be more synchronous than necessary while your tool issues management commands in batches or something like that. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Assignee: Alan Conway >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16256223#comment-16256223 ] Chris Richardson commented on QPID-7991: Just a note for posterity - the segfault under discussion did not seem to be triggered when creating the routes with the current version of qpid-route (which has recently changed to use the Broker::create API rather than the Link::Bridge approach which code comments suggest should be deprecated, see changes under https://issues.apache.org/jira/browse/QPID-7876). However it DID (prior to Alan's submitted fix) rear its ugly head when the route was created with the supposedly identical call from the c++ broker management library I authored at https://github.com/fourceu/fourc-qpid-manager and I have not yet been able to determine the exact cause. Since this fix appears to remedy the issue in either case I will abandon the investigation unless additional issues arise. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Assignee: Alan Conway >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255884#comment-16255884 ] Chris Richardson commented on QPID-7991: +1, segfault fixed! > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Assignee: Alan Conway >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255862#comment-16255862 ] Alan Conway commented on QPID-7991: --- [~chris.richardson] I think the above commit should fix the problem, I won't mark this resolved until you confirm it fixes it for you. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255857#comment-16255857 ] ASF subversion and git services commented on QPID-7991: --- Commit ab748b4d4c03703556e850f821e872bb0f03a004 in qpid-cpp's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=ab748b4 ] QPID-7991: Segfault in broker while processing active bridges Fixed incorrect use of std::remove_if while cleaning up detached bridges. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255609#comment-16255609 ] Alan Conway commented on QPID-7991: --- Excellent catch! The code as it stands is just wrong. We should process removed elements in the predicate, the standard makes no guarantees about the elements after the removed end-iterator. This might have worked with older remove_if which used std::swap to switch values to the end of the vector, but it definitely won't work with libs that use std::move, since they're almost certain to leave null pointers in the dead part of the vector. Will fix ASAP. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227319#comment-16227319
]
Chris Richardson commented on QPID-7991:
I have a theory about where the null shared_ptr may be coming from. Looking at
these lines of code (from src/qpid/broker/Link.cpp:462):
Bridges::iterator removed = std::remove_if(
active.begin(), active.end(), boost::bind(&Bridge::isDetached, _1));
for (Bridges::iterator i = removed; i != active.end(); ++i) {
Bridge::shared_ptr bridge = *i;
is it possible that the iterator holds only a pointer to the shared_ptr in the
"active" vector (which would not increment the shared_ptr ref count) and that
when it's removed from the vector the ref count may hit zero before the
iterator is referenced and assigned to the "bridge" variable?
Note that the invocation of the isDetached predicate is successfully executed
on the Bridge instance that subsequently transpired to be null, so presumably
it was not null at that time...
> Segfault in broker while processing active bridges
> --
>
> Key: QPID-7991
> URL: https://issues.apache.org/jira/browse/QPID-7991
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: Ubuntu 17.10 x86_64, gcc 7.
>Reporter: Chris Richardson
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: segfault stack trace, segfault-fix.patch,
> segfault-repoduce.tar.gz
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Segfault occurs on a brackground thread within about 5-10 seconds of broker
> startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached,
> frames #3 and #5 are of particular relevance.
> The unchecked Bridge::shared_ptr derived from the iterator is null and the
> invocation of bridge->closed() triggers the segfault. Adding a simple null
> check (as per attached [^segfault-fix.patch]) fixes the segfault but not the
> underlying reason for the null pointer.
> The segfault appears to be related to how a second broker (henceforth
> "broker1") is configured; this is the one to which the links are established.
> Without broker1, the "segfaulting broker" (aka "broker2") does not do its
> thing. It may be that broker1 returns invalid data to broker2 but this is not
> in the scope of this bug report, which focuses on the segfault.
> h2. Reproduce
> Unfortunately the steps to arrive at this situation are not clear so the
> reproduce is a bit hacky - the data directory, config file and some certs for
> the two brokers are attached as a tarball in the hope that they can be
> arranged in such a way as to provide a reproduce in lieu of a purely
> step-based procedure.
> Steps to reproduce:
> * Temporarily add a DNS alias to the local machine of "octopussy" (necessary
> due to cert config and durable link config in broker2's data store)
> * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory
> (assumed to be cwd)
> * Start broker1 with "qpidd --config broker1/qpidd.conf"
> * In another shell with the same cwd, start broker2 with "qpidd --config
> broker2/qpidd.conf"
> * Observe segfault in broker2 after 5-10 seconds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227191#comment-16227191 ] Chris Richardson commented on QPID-7991: Tested, unfortunately no stack trace triggered by the "assert" patch. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Fix For: qpid-cpp-1.37.0 > > Attachments: segfault stack trace, segfault-fix.patch, > segfault-repoduce.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, > frames #3 and #5 are of particular relevance. > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached [^segfault-fix.patch]) fixes the segfault but not the > underlying reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Temporarily add a DNS alias to the local machine of "octopussy" (necessary > due to cert config and durable link config in broker2's data store) > * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory > (assumed to be cwd) > * Start broker1 with "qpidd --config broker1/qpidd.conf" > * In another shell with the same cwd, start broker2 with "qpidd --config > broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[
https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227110#comment-16227110
]
Alan Conway commented on QPID-7991:
---
I don't have the correct version of linearstore to run the reproducer, while I
sort that out - it might be instructive to run the reproducer with this patch
and post the stack trace if there is one (hopefully!)
modified src/qpid/broker/Link.cpp
@@ -415,6 +415,7 @@ void Link::destroy ()
void Link::add(Bridge::shared_ptr bridge)
{
Mutex::ScopedLock mutex(lock);
+assert(bridge)
created.push_back (bridge);
if (connection)
connection->requestIOProcessing (
That may show us when the null pointer is getting into the Link's list.
> Segfault in broker while processing active bridges
> --
>
> Key: QPID-7991
> URL: https://issues.apache.org/jira/browse/QPID-7991
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: Ubuntu 17.10 x86_64, gcc 7.
>Reporter: Chris Richardson
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: segfault stack trace, segfault-fix.patch,
> segfault-repoduce.tar.gz
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Segfault occurs on a brackground thread within about 5-10 seconds of broker
> startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached,
> frames #3 and #5 are of particular relevance.
> The unchecked Bridge::shared_ptr derived from the iterator is null and the
> invocation of bridge->closed() triggers the segfault. Adding a simple null
> check (as per attached [^segfault-fix.patch]) fixes the segfault but not the
> underlying reason for the null pointer.
> The segfault appears to be related to how a second broker (henceforth
> "broker1") is configured; this is the one to which the links are established.
> Without broker1, the "segfaulting broker" (aka "broker2") does not do its
> thing. It may be that broker1 returns invalid data to broker2 but this is not
> in the scope of this bug report, which focuses on the segfault.
> h2. Reproduce
> Unfortunately the steps to arrive at this situation are not clear so the
> reproduce is a bit hacky - the data directory, config file and some certs for
> the two brokers are attached as a tarball in the hope that they can be
> arranged in such a way as to provide a reproduce in lieu of a purely
> step-based procedure.
> Steps to reproduce:
> * Temporarily add a DNS alias to the local machine of "octopussy" (necessary
> due to cert config and durable link config in broker2's data store)
> * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory
> (assumed to be cwd)
> * Start broker1 with "qpidd --config broker1/qpidd.conf"
> * In another shell with the same cwd, start broker2 with "qpidd --config
> broker2/qpidd.conf"
> * Observe segfault in broker2 after 5-10 seconds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7991) Segfault in broker while processing active bridges
[ https://issues.apache.org/jira/browse/QPID-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16221418#comment-16221418 ] Chris Richardson commented on QPID-7991: I'm incongruously logging this without the promised attachments in order to save the report in its current form. I also need to verify whether or not the bug applies to 1.36 or just master. > Segfault in broker while processing active bridges > -- > > Key: QPID-7991 > URL: https://issues.apache.org/jira/browse/QPID-7991 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.37.0 > Environment: Ubuntu 17.10 x86_64, gcc 7. >Reporter: Chris Richardson >Priority: Critical > Original Estimate: 48h > Remaining Estimate: 48h > > Segfault occurs on a brackground thread within about 5-10 seconds of broker > startup at src/qpid/broker/Link.cpp:465 > The unchecked Bridge::shared_ptr derived from the iterator is null and the > invocation of bridge->closed() triggers the segfault. Adding a simple null > check (as per attached patch) fixes the segfault but not the underlying > reason for the null pointer. > The segfault appears to be related to how a second broker (henceforth > "broker1") is configured; this is the one to which the links are established. > Without broker1, the "segfaulting broker" (aka "broker2") does not do its > thing. It may be that broker1 returns invalid data to broker2 but this is not > in the scope of this bug report, which focuses on the segfault. > h2. Reproduce > Unfortunately the steps to arrive at this situation are not clear so the > reproduce is a bit hacky - the data directory, config file and some certs for > the two brokers are attached as a tarball in the hope that they can be > arranged in such a way as to provide a reproduce in lieu of a purely > step-based procedure. > Steps to reproduce: > * Unpack the attached tarball to an empty directory (assumed to be cwd) > * Start the broker1 (as daemon - we are not interested in its output at this > point, available at broker1/qpidd.log if required) with "qpidd --config > broker1/qpidd.conf -d" > * Start the broker2 with "qpidd --config broker2/qpidd.conf" > * Observe segfault in broker2 after 5-10 seconds. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
