qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Exceptions crossing library boundaries abend in qpid client, gcc 4.3.1
Date Wed, 30 Jun 2010 21:15:10 GMT

I build with 1.41, but I know it works with boost versions from RHEL4 
and later.

If on RHEL 4 there is a patch in the repo to get it to compile / with 
the older version of boost in RHEL4.

 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:gsim@redhat.com]
> Sent: Tuesday, June 29, 2010 4:16 AM
> To: users@qpid.apache.org
> 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/tahoe-dev@allmydata.org/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:users-subscribe@qpid.apache.org
>>
>>      
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>    


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message