Qpid
  1. Qpid
  2. QPID-5366

qpid segfaults in qpid::ha::BrokerReplicator::disconnected

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.24
    • Fix Version/s: 0.26
    • Component/s: C++ Clustering
    • Labels:
      None

      Description

      Relocating the qpidd-primary service while the cluster is under load was causing sporadic core dumps in BrokerReplicator::disconnected. For details see:

      https://bugzilla.redhat.com/show_bug.cgi?id=1030608

        Activity

        Hide
        ASF subversion and git services added a comment -

        Commit 1543893 from Alan Conway in branch 'qpid/trunk'
        [ https://svn.apache.org/r1543893 ]

        QPID-5366: qpid segfaults in qpid::ha::BrokerReplicator::disconnected

        Fix for a race condition: previously, BrokerReplicator created a separate
        ConnectionObserver object to forward connection events to it. However the
        Observers locking is such that it is possible for an event to arrive after
        calling Observers::remove (Observers copies the pointers and delivers events
        outside its lock.) This meant that it was possible for a call to
        BrokerReplicator::disconnect to be made after the BrokerReplicator was deleted.

        The fix is to combine BrokerReplicator and BrokerReplicator::ConnectionObserver
        into a single object with one lifetime that will last until it is removed from
        both the ExchangeRegistry and the ConnectionObservers.

        Show
        ASF subversion and git services added a comment - Commit 1543893 from Alan Conway in branch 'qpid/trunk' [ https://svn.apache.org/r1543893 ] QPID-5366 : qpid segfaults in qpid::ha::BrokerReplicator::disconnected Fix for a race condition: previously, BrokerReplicator created a separate ConnectionObserver object to forward connection events to it. However the Observers locking is such that it is possible for an event to arrive after calling Observers::remove (Observers copies the pointers and delivers events outside its lock.) This meant that it was possible for a call to BrokerReplicator::disconnect to be made after the BrokerReplicator was deleted. The fix is to combine BrokerReplicator and BrokerReplicator::ConnectionObserver into a single object with one lifetime that will last until it is removed from both the ExchangeRegistry and the ConnectionObservers.
        Hide
        Gordon Sim added a comment -

        I have reviewed the change and would be in favour of merging to 0.26

        Show
        Gordon Sim added a comment - I have reviewed the change and would be in favour of merging to 0.26
        Hide
        Justin Ross added a comment -

        Reviewed by Gordon. Approved for 0.26.

        Show
        Justin Ross added a comment - Reviewed by Gordon. Approved for 0.26.
        Hide
        ASF subversion and git services added a comment -

        Commit 1544246 from Alan Conway in branch 'qpid/branches/0.26'
        [ https://svn.apache.org/r1544246 ]

        QPID-5366: qpid segfaults in qpid::ha::BrokerReplicator::disconnected

        Fix for a race condition: previously, BrokerReplicator created a separate
        ConnectionObserver object to forward connection events to it. However the
        Observers locking is such that it is possible for an event to arrive after
        calling Observers::remove (Observers copies the pointers and delivers events
        outside its lock.) This meant that it was possible for a call to
        BrokerReplicator::disconnect to be made after the BrokerReplicator was deleted.

        The fix is to combine BrokerReplicator and BrokerReplicator::ConnectionObserver
        into a single object with one lifetime that will last until it is removed from
        both the ExchangeRegistry and the ConnectionObservers.

        Show
        ASF subversion and git services added a comment - Commit 1544246 from Alan Conway in branch 'qpid/branches/0.26' [ https://svn.apache.org/r1544246 ] QPID-5366 : qpid segfaults in qpid::ha::BrokerReplicator::disconnected Fix for a race condition: previously, BrokerReplicator created a separate ConnectionObserver object to forward connection events to it. However the Observers locking is such that it is possible for an event to arrive after calling Observers::remove (Observers copies the pointers and delivers events outside its lock.) This meant that it was possible for a call to BrokerReplicator::disconnect to be made after the BrokerReplicator was deleted. The fix is to combine BrokerReplicator and BrokerReplicator::ConnectionObserver into a single object with one lifetime that will last until it is removed from both the ExchangeRegistry and the ConnectionObservers.

          People

          • Assignee:
            Alan Conway
            Reporter:
            Alan Conway
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development