You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Geoff Simmons (JIRA)" <ji...@apache.org> on 2012/11/25 19:18:58 UTC
[jira] [Created] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Geoff Simmons created AMQCPP-442:
------------------------------------
Summary: 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
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: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Geoff Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Simmons updated AMQCPP-442:
---------------------------------
Attachment: bt3.txt
bt2.txt
amq.cpp
amq.h
The attachments include the header and C++ source for the class that encapsulates the MessageProducer and ActiveMQConnection (the AMQ_* functions form the C interface).
One of the stacktraces shows a segfault in memmove(), and the other one shows an abort in free(). (Both signals are intercepted by a signal handler that logs the stacktrace to syslog and then aborts.)
> 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
> 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Geoff Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505532#comment-13505532 ]
Geoff Simmons commented on AMQCPP-442:
--------------------------------------
No luck with v3.4.5, I just got the segfault from memmove again, and the stack trace is about the same.
I'll see if I can work up a test app.
> 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
> 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505804#comment-13505804 ]
Timothy Bish commented on AMQCPP-442:
-------------------------------------
It should work fine in any thread.
> 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Geoff Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505795#comment-13505795 ]
Geoff Simmons commented on AMQCPP-442:
--------------------------------------
Quick question -- is there an expectation by design that multi-threaded apps use the decaf Thread implementation? Or would you expect it to be possible to use objects from AMQ-CPP, such as the MessageProducer and ActiveMQConnection encapsulated in the attached class, within pthreads of a C app?
> 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505771#comment-13505771 ]
Timothy Bish commented on AMQCPP-442:
-------------------------------------
A repeatable test case would help. Also you can try the latest v3.5.0 SNAPSHOT build, code is here: http://people.apache.org/~tabish/cms-3.5.x/
> 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Geoff Simmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505573#comment-13505573 ]
Geoff Simmons commented on AMQCPP-442:
--------------------------------------
BTW, the version number has apparently not been updated in all parts of the installation. The include directory, as well as the Version tag in activemq-cpp.pc, all have the label 3.4.4, but according to ls -l, these are the newly installed files.
> 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
[jira] [Updated] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Geoff Simmons (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (AMQCPP-442) Segfaults, aborts in
ActiveMQConnection::close()/InactivityMonitor::close()
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQCPP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503791#comment-13503791 ]
Timothy Bish commented on AMQCPP-442:
-------------------------------------
I'd first recommend that you try with the latest released code v3.4.5. If you still see a problem then it'd be helpful for you to provide a fully functioning test app that demonstrates the problem.
> 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
> 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