You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Mike J. Kitchin" <Mi...@Tideworks.com> on 2010/03/01 21:37:01 UTC
Authentication error leads to pure virtual call/kaboom in CMS 3.1.1
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.
-Regards,
MjK
- - - - -
"Here lies Zeke, second-fastest draw in Cripple Creek."
- Epitaph (Cripple Creek, CO)
Michael J. Kitchin (Senior Software Engineer)
Tideworks Technology
http://www.tideworks.com
Re: Authentication error leads to pure virtual call/kaboom in CMS
3.1.1
Posted by Timothy Bish <ta...@gmail.com>.
On Mon, Mar 1, 2010 at 3:37 PM, Mike J. Kitchin
<Mi...@tideworks.com>wrote:
> 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.
>
> If you could open a new Jira issue that documents the problem and attach
the information provided to reproduce the error. I'd like to take a look at
this once I return the office at the end of the week. Any and all
information you can provide to help me reproduce the error is appreciated.
Knowing your prlatform OS and compler would be helpful as well as would any
stack traces that you have captured during this error.
Regards
Tim
> 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.
>
> -Regards,
> MjK
>
> - - - - -
>
> "Here lies Zeke, second-fastest draw in Cripple Creek."
> - Epitaph (Cripple Creek, CO)
>
> Michael J. Kitchin (Senior Software Engineer)
> Tideworks Technology
> http://www.tideworks.com
>
>
>
RE: Authentication error leads to pure virtual call/kaboom in CMS
3.1.1
Posted by "Mike J. Kitchin" <Mi...@Tideworks.com>.
Hi there,
Added to the Jira, here:
https://issues.apache.org/activemq/browse/AMQCPP-290
Thanks again :)
-Regards,
MjK
> -----Original Message-----
> From: Mike J. Kitchin [mailto:Mike.Kitchin@Tideworks.com]
> Sent: Monday, March 01, 2010 12:37 PM
> To: users@activemq.apache.org
> Subject: Authentication error leads to pure virtual call/kaboom in CMS
> 3.1.1
>
> 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.
>
> -Regards,
> MjK
>
> - - - - -
>
> "Here lies Zeke, second-fastest draw in Cripple Creek."
> - Epitaph (Cripple Creek, CO)
>
> Michael J. Kitchin (Senior Software Engineer) Tideworks Technology
> http://www.tideworks.com
>