activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Helen Huang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQCPP-405) CMS sender thread hangs after restarting broker
Date Thu, 08 Nov 2012 14:49:13 GMT

     [ https://issues.apache.org/jira/browse/AMQCPP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Helen Huang updated AMQCPP-405:
-------------------------------

    Attachment: CrashHang_Report__CMSMessageHandlerCOM-TestMultipleSendersReceivers.exe__11072012173926312.mht

Please find more information on the access violation in the latest dump: CrashHang_Report__CMSMessageHandlerCOM-TestMultipleSendersReceivers.exe__11072012173926312.mht

Analysis:
The HTML file indicates that this was a hang.  Thread 15 (ID 0xDF8, 3576 decimal) was exiting.
 Thread 23 (ID 0x2290, 8848 decimal) seems to have been waiting on a critical section structure
owned by thread 15 as it too was exiting.  Thread 18 (ID 0x1C8C, 7308 decimal) seems to have
been attempting to initiate a new thread on a callback exception and was waiting on the same
critical section structure.  Attempted use of a released critical section structure often
seems to turn off bits in the address, which would result in a memory access violation.
 
The HTML gives the recommendation to enable "lock checks" in Application Verifier for the
test tool.
 
The dump from 11/1 is identified in CrashHang_Report__SCOTApp_exe__11012012195321234.mht as
a deadlock.  It could possibly be related to the new condition, but it was mixed up with memory
corruption that makes a single cause difficult to guess at.
 
The latest problem is probably a timing issue, with two threads exiting as a third is trying
to start a new thread, as shown in the call stack below for thread 18.  Callbacks probably
need to be disabled as part of the termination process, with a critical section lock needed
while the callback thread terminates.
 
Call stack:
ntdll!KiFastSystemCallRet    
ntdll!ZwWaitForSingleObject+c    
ntdll!RtlpWaitForCriticalSection+132    
ntdll!RtlEnterCriticalSection+46    
ntdll!LdrpGetProcedureAddress+117    
ntdll!LdrGetProcedureAddress+18    
kernel32!GetProcAddress+43    
msvcr80d!_initptd+88    
msvcr80d!_beginthreadex+b3    
activemq_cppud!decaf::internal::util::concurrent::PlatformThread::createNewThread+25    
activemq_cppud!`anonymous namespace'::createThreadInstance+94    
activemq_cppud!decaf::internal::util::concurrent::Threading::createNewThread+103    
activemq_cppud!decaf::lang::Thread::initializeSelf+1a8    
activemq_cppud!decaf::lang::Thread::Thread+5c    
activemq_cppud!activemq::core::ConnectionThreadFactory::newThread+117    
activemq_cppud!decaf::util::concurrent::ExecutorKernel::Worker::Worker+f4    
activemq_cppud!decaf::util::concurrent::ExecutorKernel::addWorker+15e    
activemq_cppud!decaf::util::concurrent::ExecutorKernel::execute+da    
activemq_cppud!decaf::util::concurrent::ThreadPoolExecutor::execute+76    
activemq_cppud!activemq::core::ActiveMQConnection::onException+f7    
activemq_cppud!activemq::transport::TransportFilter::fire+54    
activemq_cppud!activemq::transport::TransportFilter::onException+16    
activemq_cppud!activemq::transport::correlator::ResponseCorrelator::onException+3e    
activemq_cppud!activemq::transport::TransportFilter::fire+54    
activemq_cppud!activemq::wireformat::openwire::OpenWireFormatNegotiator::onException+27  
 
activemq_cppud!activemq::transport::TransportFilter::fire+54    
activemq_cppud!activemq::transport::TransportFilter::onException+16    
activemq_cppud!activemq::transport::inactivity::InactivityMonitor::onException+3a    
activemq_cppud!activemq::transport::TransportFilter::fire+54    
activemq_cppud!activemq::transport::TransportFilter::onException+16    
activemq_cppud!activemq::transport::IOTransport::fire+5f    
activemq_cppud!activemq::transport::IOTransport::run+148    
activemq_cppud!decaf::lang::Thread::run+2b    
activemq_cppud!`anonymous namespace'::runCallback+4a    
activemq_cppud!`anonymous namespace'::threadEntryMethod+12f    
msvcr80d!_callthreadstartex+51    
msvcr80d!_threadstartex+87    
kernel32!BaseThreadStart+37 

                
> CMS sender thread hangs after restarting broker
> -----------------------------------------------
>
>                 Key: AMQCPP-405
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-405
>             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: Critical
>             Fix For: 3.5.0
>
>         Attachments: CrashHang_Report__CMSMessageHandlerCOM-TestMultipleSendersReceivers.exe__11072012173926312.mht,
CrashHang_Report__CMSMessageHandlerCOM-TestReceiver.exe__10242012114621213.mht, CrashHang_Report__CMSMessageHandlerCOM-TestSender_exe__1001201211243973.mht,
CrashHang_Report__CMSMessageHandlerCOM-TestSender_exe__1001201220471946.mht, CrashHang_Report__CMSMessageHandlerCOM-TestSender_exe__10022012152424484.mht,
CrashHang_Report__CMSMessageHandlerCOM-TestSender_exe__10032012172730765.mht, CrashHang_Report__PID_2832__05232012143544484.mht,
CrashHang_Report__SCOTApp.exe__10272012120620437.mht, CrashHang_Report__SCOTApp_exe__11012012195321234.mht
>
>
> The sender thread in CMS hangs after we retarted the message broker.
> The thread is 548 in the attached dump file. 
> This is a critical issue that blocks the release of our product that is scheduled in
a few days. We hope you can resolve it soon. Really appreciate your help!

--
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

Mime
View raw message