[
https://issues.apache.org/activemq/browse/AMQCPP-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57940#action_57940
]
Michael J. Kitchin commented on AMQCPP-290:
-------------------------------------------
Browsing through the stack traces, I see that in "IOTransport::fire"
(IOTransport.cpp:73) there's a "!this->closed" check prior to calling the
observing listener's "onException" method (in this case, a TransportFilter
which re-fires it to another), however at the time the assert is tripped and I
examine the app in the debugger "this->closed" resolves to true, suggesting a
race condition. I note "closed" in "IOTransport" is already volatile, so
perhaps some sort of lock?
> Authentication error leads to pure virtual call/kaboom in CMS 3.1.1
> -------------------------------------------------------------------
>
> Key: AMQCPP-290
> URL: https://issues.apache.org/activemq/browse/AMQCPP-290
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.1
> Environment: Windows7/32bit, Windows Server 2003/32bit (clients),
> Windows7/Windows Server/WindowsXP (broker)
> Reporter: Michael J. Kitchin
> Assignee: Timothy Bish
> Attachments: amqcms_simpleproducer_03_01_10_1.cpp,
> amqcms_stack_traces_03_01_10_1.txt
>
>
> Hi there,
> We have a large, vertical C++ application with ActiveMQ connectivity added
> about a year ago, steadily upgrading the CMS interface until current (v3.1.1)
> and, beginning before 3.0.1, we noticed after consecutive login failures --
> within our app, it takes from 3-10 actual retries -- we find a pure virtual
> function call somewhere in the AMQ thread pool, triggering our built-in
> crashdump mechanism and shutting things down.
> An exception that's at least cosmetically similar may be reproduced with the
> SimpleProducer, as I've doctored it and attached to this email (not sure if
> attachments make it to the list...), along with the thread stacks/traces
> witnessed at the time. Start SimpleProducer and, after an indeterminate
> number of retries -- in this example, it could take several hundred -- the
> circumstance should arise. The test is performed between two hosts, using AMQ
> broker v5.3 and CMS 3.1.1 and ought to manifest in either debug/release build.
> SimpleProducer has been altered to:
> ===================================
> - Provide username/password (in our test case, the username "foo" is
> incorrect)
> - Connect to a remote v5.3 AMQ broker
> - Loop the example indefinitely with a short delay between retries until (in
> a debug build) a pure virtual assert should trip in the standard library
> Our application is built unusually in the following ways:
> =========================================================
> - AMQ CMS and APR are all reconfigured and built __stdcall, since our main
> application is that way and name mangling won't otherwise match at link time
> - We don't have STL debug iterators enabled, so key AMQ CMS/APR headers are
> prepended with (more or less):
> #ifdef _HAS_ITERATOR_DEBUGGING
> #undef _HAS_ITERATOR_DEBUGGING
> #endif
> #define _HAS_ITERATOR_DEBUGGING 0
> ...This may seem like an odd circumstance, but we function in enterprises
> where AMQ connectivity is only part of what our application is responsible
> for and, occasionally (for example) brokers may be misconfigured and remain
> so for notable periods before changes make their way to all of the clients,
> during which time we must remain operational in other regards. In practice,
> as I've said, our application will experience the pure virtual call within a
> few minutes.
> Thank you for your time/assistance, in advance, and we otherwise very much
> appreciate the functionality AMQ/CMS provides us.
> Please let me know if I may provide any additional information. Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
