activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-407) Application crashes after stopping message broker
Date Thu, 31 May 2012 22:52:23 GMT

    [ 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

        

Mime
View raw message