activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Simmons (JIRA)" <>
Subject [jira] [Created] (AMQCPP-442) Segfaults, aborts in ActiveMQConnection::close()/InactivityMonitor::close()
Date Sun, 25 Nov 2012 18:18:58 GMT
Geoff Simmons created AMQCPP-442:

             Summary: Segfaults, aborts in ActiveMQConnection::close()/InactivityMonitor::close()
                 Key: AMQCPP-442
             Project: ActiveMQ C++ Client
          Issue Type: Bug
          Components: CMS Impl
    Affects Versions: 3.4.4
         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

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:

View raw message