[
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
