You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2012/06/01 00:52:23 UTC
[jira] [Commented] (AMQCPP-407) Application crashes after stopping
message broker
[ https://issues.apache.org/jira/browse/AMQCPP-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287019#comment-13287019 ]
Timothy Bish commented on AMQCPP-407:
-------------------------------------
The scenario shown above shouldn't happen as the ActiveMQConnection should go through the close() cycle when the destructor is called if it hasn't already been closed. During the close the Transports have their close method called which eventually reaches IOTransport::close. The IOTransport will stop its dispatch thread which is the thread that's calling the onException method via the registered ExceptionListsner. In IOTransport close the dispatch thread is joined which should halt ActiveMQConnection close until such time as the last onException fire is finished. So the solution here is to determine what is causing this to not happen.
Adding a get / set synchronization won't likely help here or worse will make the problem even more random and therefore much harder to reproduce and fix. The issue being that a synchronization is only serializing the get / set operation on exception listener, so if your scenario above is indeed happening there's still nothing stopping the event firing from reading the exception listener before another thread sets it to null. Locking the entire onExcption callback chain will most likely lead to an unexpected deadlock as the code attempts to deal with errors from the exception thread which will be holding locks that block the other threads accessing the ActiveMQConnection and associated resources.
Mutex's are often treated as a panacea for threading problems.
If you can readily reproduce this then I'd advise stepping into the IOException close method or adding some console output in there to see if the close is bypassing the Thread join because of some other exception. One solution could be to use a finalizer class in there to ensure that the thread is always joined.
> Application crashes after stopping message broker
> -------------------------------------------------
>
> Key: AMQCPP-407
> URL: https://issues.apache.org/jira/browse/AMQCPP-407
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
> Affects Versions: 3.4.1
> Environment: Windows xp service pack 3, ActiveMQ broker 5.3.1, apr 1.4.2, apr-util 1.3.9, apr iconv 1.2.1
> Reporter: Helen Huang
> Assignee: Timothy Bish
> Priority: Blocker
> Fix For: 3.4.1
>
> Attachments: AttemptedFix1.7z
>
>
> Stopping the message broker would crash our application. The following is the call stack of the fault thread.
> Thread 0 - System ID 672
> Entry point msvcr80!endthreadex+61
> Create time 5/24/2012 1:53:56 PM
> Time spent in user mode 0 Days 0:0:0.46
> Time spent in kernel mode 0 Days 0:0:0.78
> Function Arg 1 Arg 2 Arg 3 Source
> kernel32!InterlockedDecrement+9 00000000 00000000 00242110
> msvcrt!cexit+f 77c10000 00000000 00000001
> ntdll!LdrInitializeThunk+24 77c1f2a1 77c10000 00000000
> ntdll!RtlDestroyEnvironment+178 00000000 0eec256d 00000001
> kernel32!IsValidLocale+8eb 00000003 77e8f3b0 ffffffff
> kernel32!ExitProcess+14 00000003 0ec21a04 00000003
> msvcr80!amsg_exit+5e 00000003 00000001 00000000
> msvcr80!exit+d 1795efe0 00000000 ffffffff
> user32!MessageBoxIndirectA+23a 00000001 7c91005d 13946b5e
> user32!MessageBoxIndirectA+254 13946b5e 00000000 00e30850
> ntdll!RtlFreeHeap+130 0468001b 00000202 1795f110
> activemq_cppu!activemq::core::ActiveMQConnection::onException+fd 1795fe24 7f427d47 1795fe18
> activemq_cppu!activemq::transport::TransportFilter::fire+44 1795fe24 7f427d33 1795fe18
> activemq_cppu!activemq::transport::TransportFilter::fire+44 1795fe24 7f427cef 1795fe18
> activemq_cppu!activemq::transport::TransportFilter::fire+44 1795fe24 1795f60c 0ef4a264
> activemq_cppu!activemq::transport::inactivity::InactivityMonitor::onException+33 1795fe24 7f427cd7 1795fe18
> activemq_cppu!activemq::transport::TransportFilter::fire+44 1795fe24 7f427c83 1795fe18
> activemq_cppu!activemq::transport::IOTransport::fire+4b 1795fe24 0ec48ed7 1795fe18
> activemq_cppu!activemq::transport::IOTransport::run+15e 7f427107 7c809c65 12519500
> activemq_cppu!decaf::lang::ThreadProperties::runCallback+82 7c936d80 04682060 0ec229bb
> activemq_cppu!`anonymous namespace'::threadWorker+20 04682060 0ec229bb 12519500
> ntdll!RtlRemoveVectoredExceptionHandler+2a2 04682060 7c80b729 1252f168
> msvcr80!endthreadex+c7 0ec229e1 1252f168 00000000
> KERNEL32!INTERLOCKEDDECREMENT+9WARNING - DebugDiag was not able to locate debug symbols for kernel32.dll, so the information below may be incomplete.
> In ScotAppU__PID__1168__Date__05_24_2012__Time_02_18_41PM__916__Second_Chance_Exception_C0000005.dmp the assembly instruction at kernel32!InterlockedDecrement+9 in C:\WINDOWS\system32\kernel32.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to write to memory location 0x014718e4 on thread 0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira