Hi, One last update. My problem turned out to be a simple buffer overrun, not any weird gcc bug. (Who woulda thought? Occam's Razor: The simplest explanations are usually the best.)
There was a global variable declared just ahead of the clobbered std::type_info vtable object, and our application code wrote off the end of the buffer. That explains why no-one else has seen this bug. Thanks again for the good suggestions. I learned a lot in debugging this problem. Regards, Dave -----Original Message----- From: Birdsall, Dave Sent: Thursday, July 01, 2010 3:43 PM To: [email protected] Subject: RE: Exceptions crossing library boundaries abend in qpid client, gcc 4.3.1 Hi, Just an update. I hacked around awhile with qpid library builds, trying to glue libraries together -- on the theory that removing library boundaries would get rid of any gcc problem with throwing exceptions across them. Couldn't get that to work. Then I put the make files back to their original state and rebuilt once more, supposedly bringing back the libraries to original state. My abend now goes away. I suspect but have no proof that this is evidence to support my original guess that this is a gcc problem; and the luck of the draw in linking this time seemed to make the symptom go away. Regards, Dave -----Original Message----- From: Gordon Sim [mailto:[email protected]] Sent: Thursday, July 01, 2010 12:02 AM To: [email protected] Subject: Re: Exceptions crossing library boundaries abend in qpid client, gcc 4.3.1 On 06/30/2010 10:15 PM, Carl Trieloff wrote: > > I build with 1.41, but I know it works with boost versions from RHEL4 > and later. 1.33, 1.37 work fine, I don't think its the boost version (providing the version qpid was built against is the same one the application uses). > If on RHEL 4 there is a patch in the repo to get it to compile / with > the older version of boost in RHEL4. > https://bugzilla.redhat.com/show_bug.cgi?id=559222 > From FC6 and RHEL5, onwards boost version packaged should cause no issues. > > Carl. > > > On 06/30/2010 11:23 AM, Birdsall, Dave wrote: >> Hi, >> >> I'm using Boost 1.35.0. >> >> I looked at the Apache Qpid web site but did not see recommentations >> of which version to use with a given version of qpid. >> >> I did notice that we were using Boost libraries compiled with gcc >> 4.1.2. I rebuilt them yesterday using gcc 4.3.1 (bringing all my >> libraries into line with the same version of gcc), but the symptom >> remains as before. (By the way, for anyone wanting to re-build Boost >> with a different version of gcc, I found that the Boost build tool, >> bjam, uses the first instance of g++ that it finds in your PATH.) >> >> Would you recommend a different version of Boost? >> >> Thanks and kind regards, >> >> Dave >> >> -----Original Message----- >> From: Gordon Sim [mailto:[email protected]] >> Sent: Tuesday, June 29, 2010 4:16 AM >> To: [email protected] >> Subject: Re: Exceptions crossing library boundaries abend in qpid >> client, gcc 4.3.1 >> >> On 06/28/2010 09:22 PM, Birdsall, Dave wrote: >>> Hi all, >>> >>> I'm using qpid 0.5, built using gcc 4.3.1 on Linux Red Hat distribution. >>> >>> I'm debugging a rather vexing abend with the following stack trace >>> >>> #0 0x726f6371 in ?? () >>> #1 0xf72aa52c in get_adjusted_ptr (catch_type=0xf72d9430, >>> throw_type=0xf6bd575c, thrown_ptr_p=0xffe3d9f8) at >>> ../../../.././libstdc++-v3/libsupc++/eh_personality.cc:241 >>> #2 0xf72aaf97 in __gxx_personality_v0 (version=1, actions=1, >>> exception_class=<value optimized out>, ue_header=0xf3d46750, >>> context=0xffe3db10) >>> at ../../../.././libstdc++-v3/libsupc++/eh_personality.cc:586 >>> #3 0x00528ceb in _Unwind_RaiseException () from /lib/libgcc_s.so.1 >>> #4 0xf72ab25d in __cxa_throw (obj=0xf3d46770, tinfo=0xf6bd575c, >>> dest=0xf6b28942<qpid::TransportFailure::~TransportFailure()>) >>> at ../../../.././libstdc++-v3/libsupc++/eh_throw.cc:71 >>> #5 0xf6b37c4c in >>> qpid::sys::ExceptionHolder::Wrapper<qpid::TransportFailure>::raise () >>> from >>> /home/bermanbe/cvs_HEAD_test/seapilot/thirdparty_export/lib/libqpidclient.so.0 >>> >>> #6 0xf6b1b855 in qpid::sys::ExceptionHolder::raise () from >>> /xxx/thirdparty_export/lib/libqpidclient.so.0 >>> #7 0xf6b6afd4 in qpid::client::SessionImpl::check () from >>> /xxx/thirdparty_export/lib/libqpidclient.so.0 >>> #8 0xf6b6b1d2 in qpid::client::SessionImpl::checkOpen () from >>> /xxx/thirdparty_export/lib/libqpidclient.so.0 >>> #9 0xf6b6ef63 in qpid::client::SessionImpl::sendCommand () from >>> /xxx/seapilot/thirdparty_export/lib/libqpidclient.so.0 >>> #10 0xf6b6f1a7 in qpid::client::SessionImpl::send () from >>> /xxx/seapilot/thirdparty_export/lib/libqpidclient.so.0 >>> ... >>> >>> I get into this code path because my subsystem has intentionally >>> killed the broker before killing the broker client. Which is easy for >>> me to resolve in most situations. But... >>> >>> It seems the typeinfo object for a qpid::TransportFailure object has >>> a bad vtable pointer. I'm guessing this is a manifestation of a >>> well-known RTTI bug in gcc where RTTI information is not properly >>> resolved across shared library boundaries. (See, for example, >>> http://www.mail-archive.com/[email protected]/msg03213.html, or >>> http://mail.python.org/pipermail/cplusplus-sig/2009-May/014531.html.) >>> >>> It seems I'm at risk of this sort of abend whenever any exception is >>> thrown in libqpidclient.so where the exception object type is shared >>> with libqpidcommon.so. At least until upgrading to gcc 4.5. >>> >>> Have others encountered this problem? >> I haven't ever come across this. I use gcc 4.1.2 and 4.4.1 (and even, >> though less frequently, 3.4.6) and have done lots of testing where the >> broker is killed from 'beneath' running clients. (Note this has not been >> specifically on 0.5, though I'm not aware of any change that might have >> 'fixed' this either). >> >> Is it possible boost versions are an issue here? >> >>> How have you worked around it? >>> >>> Thanks and kind regards, >>> >>> Dave Birdsall >>> >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:[email protected] >>> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
