[
https://issues.apache.org/jira/browse/AMQCPP-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Godin updated AMQCPP-617:
----------------------------------
Affects Version/s: 3.9.2
3.9.4
> Segfault when using a QueueBrowser.
> -----------------------------------
>
> Key: AMQCPP-617
> URL: https://issues.apache.org/jira/browse/AMQCPP-617
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.9.2, 3.9.4
> Reporter: Francois Godin
> Assignee: Timothy Bish
> Priority: Critical
>
> I encountered a rare (but that still happened a couple of time) crash due to
> the ActiveMQ C++ library.
> h2. Information
> I've done some digging and the crash happen when the function
> activemq::core::Browser::dispatch call
> activemq::core::ActiveMQQueueBrowser::notifyMessageAvailable. The segfault
> happen at the first member access in ActiveMQQueueBrowser.
> h3. Core dump
> #0 0x00007f38f7736758 in decaf::util::concurrent::Lock::lock() ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #1 0x00007f38f7736875 in
> decaf::util::concurrent::Lock::Lock(decaf::util::concurrent::Synchronizable*,
> bool) ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #2 0x00007f38f73f0f5d in
> activemq::core::ActiveMQQueueBrowser::notifyMessageAvailable() ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #3 0x00007f38f73f4cd1 in
> activemq::core::Browser::dispatch(decaf::lang::Pointer<activemq::commands::MessageDispatch,
> decaf::util::concurrent::atomic::AtomicRefCounter> const&) ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #4 0x00007f38f7406c24 in
> activemq::core::ActiveMQSessionExecutor::dispatch(decaf::lang::Pointer<activemq::commands::MessageDispatch,
> decaf::util::concurrent::atomic::AtomicRefCounter> const&) ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #5 0x00007f38f7407ce5 in activemq::core::ActiveMQSessionExecutor::iterate()
> ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #6 0x00007f38f7543565 in activemq::threads::DedicatedTaskRunner::run() ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #7 0x00007f38f76acbef in ?? ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #8 0x00007f38f76ac964 in ?? ()
> from
> /home/Fasttracctest/daemon/FastTraccTestDaemon/lib/libactivemq-cpp.so.19
> #9 0x00007f38f9120aa1 in start_thread () from /lib64/libpthread.so.0
> #10 0x00007f38f941eaad in ioperm () from /lib64/libc.so.6
> #11 0x0000000000000000 in ?? ()
> h3. Usage of the library
> int getMessageCountInQueue(cms::Session* session, cms::Queue* queue) {
> std::unique_ptr<cms::QueueBrowser>
> browser(session->createBrowser(queue));
> cms::MessageEnumeration* enumeration = browser->getEnumeration();
> int count = 0;
> while(enumeration->hasMoreMessages()) {
> count++;
> cms::Message* msg = enumeration->nextMessage();
> delete msg;
> }
> return count;
> }
> h2. After some analysis, I have the following hypothesis:
> It seems that when I destroy the ActiveMQQueueBrowser (and thus call
> destroyConsumer), the Browser instance that refer to it may be kept alive by
> activemq::core::ActiveMQSessionExecutor::dispatch (as it is stored in a
> shared_ptr).
> Often it is no problem as Browser::dispatch is not called but I guess it may
> happen rarely and cause the segfault.
> h2. Proposed solution
> The basic ActiveMQConsumerKernel::dispatch should be protected against that
> problem because it lock and check if the consumer is closed (which it is). It
> just happen that the Browser::dispatch did not have those check and thus will
> always execute the code.
> As such, I propose splitting ActiveMQConsumerKernel::dispatch into two:
> # The cleanup, locking and check into the new ActiveMQConsumerKernel::dispatch
> # The operation itself into ActiveMQConsummerKernel::dispatchImpl.
> Then, Browser only need to override dispatchImpl and will have the same
> protection that ActiveMQConsumerKernel had.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
