[
https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Simmons updated AMQCPP-442:
---------------------------------
Affects Version/s: 3.4.5
> Segfaults, aborts in ActiveMQConnection::close()/InactivityMonitor::close()
> ---------------------------------------------------------------------------
>
> Key: AMQCPP-442
> URL: https://issues.apache.org/jira/browse/AMQCPP-442
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
> Affects Versions: 3.4.4, 3.4.5
> Environment: Debian 6.0.6, Linux kernels 2.6.32 and 3.2.0, AMD 64 bit
> (uname -a = Linux gsimmons 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.32-1~bpo60+1
> x86_64 GNU/Linux)
> OpenSolaris b134 (Solaris 10), AMD 64 bit
> Reporter: Geoff Simmons
> Assignee: Timothy Bish
> Attachments: amq.cpp, amq.h, bt2.txt, bt3.txt
>
>
> I'm working on a C application that uses AMQ-CPP 3.4.4 to send messages to an
> ActiveMQ broker. The app encompasses a C++ class that encapsulates the
> MessageProducer and ActiveMQ connection, and it uses an instance of the class
> in each of a group of worker threads (Unix pthreads) that send the messages
> (I'll attach the header and CPP source for the class). I've been testing with
> 10, 15 and 20 worker threads.
> The app is experiencing intermittent crashes in the destructor for
> activemq::core::ActiveMQConnection, when ActiveMQConnection::close() is
> called (when it's time to shut down the app's worker threads). In the lowest
> levels of the stacktrace, there is apparently an attempt to free or move
> unallocated memory, causing either a segfault or abort (I'll also attach
> stack traces). Most of the time, the connection closes normally; I haven't
> been able to identify circumstances under which the crashes occur.
> I'm new to AMQ-CPP, but here's my guess as to what's happening: as a part of
> the connection close,
> activemq::transport::inactivity::InactivityMonitor::close() is called. That
> in turn calls activemq::threads::CompositeTaskRunner::shutdown(), which calls
> decaf::lang::Thread::currentThread(). currentThread() calls
> pthread_getspecific() with the key currentThreadKey, which returns NULL, so
> Thread::createForeignThreadInstance() is called. But that doesn't seem right
> -- the connection is being closed so that the current pthread can be shut
> down.
> At any rate, the stacktrace after the crashes have always included
> InactivityMonitor::close() -> CompositeTaskRunner::shutdown() ->
> Thread::currentThread() -> Thread::createForeignThreadInstance().
> Of course, I may be setting things up incorrectly. Is there an assumption
> that ActiveMQConnections are called from decaf Threads, rather than from
> pthreads in C?
> The problem is not critical because the app is about to shut down anyway. As
> a workaround to prevent connection closes before shutdown, I'm using
> wireFormat.maxInactivityDuration=0 in the MQ URI.
> libactivemq was built from source.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
