Hi Jeremy and Rabih,
I think the problem is in the way you have constructed your Session class.
The fact that you have a proton::session object "m_session" embedded
in your Session object, and the Session object's destructor is called
in the non-callback thread, means that you are making an unsaf
Hello,
We manage to reproduce the bug in a simplified use case.
Please find attached the "Broker.hpp" along with the test "Main.cpp".
The usage was inspired from the proton C++ multi-threaded examples and the
doc:
https://github.com/apache/qpid-proton/blob/master/cpp/docs/mt.md#thread-safety-rules
I am of the same opinion as Gordon that fixing the counting (to be atomic)
will only address the current symptom without preventing other races that
will present themselves later or on other hardware architectures.
Having two threads participating in Proton object reference counting is
problematic
On 19/04/2019 11:02 am, Rabih M wrote:
We are only using proton objects in the handler, however, at destruction
time, there is a race condition on the reference counter between the proton
objects from the main thread that are being destroyed, and the proton
objects held by the proton thread.
Ca
Hello,
We are using proton 0.27.0.
We are facing segfaults due to race conditions on the ref counting
mechanism of proton C at destruction time.
We are only using proton objects in the handler, however, at destruction
time, there is a race condition on the reference counter between the proton
obj
