[
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
