[C++-sig] Re: Multiple typeinfos causing failure of exception catches

[David Abrahams]

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> I've been having major problems with getting exceptions to traverse 
> shared object boundaries with Boost.Python using GCC and Linux. There 
> is a core SO called libTnFOX-0.80.so which is linked against by 
> TnFOX.so, the BPL extension and these are linked into TestEmbedPython 
> which is an executable.
>
> Now when python has an exception, I have it translate it into a C++ 
> exception which it throws. In theory, TnFOX.so should throw a 
> FXPythonException instance which in theory gets caught in 
> TestEmbedPython. All is good under Win32, but on GCC & Linux you get 
> "uncaught exception" and a terminate(). I have examined the dynamic 
> symbol table in each binary and a typeinfo for FXPythonException 
> appears in TnFOX.so and TestEmbedPython.
>
> I did some searching and found:
>
> http://gcc.gnu.org/ml/gcc/2002-05/msg00995.html
>
> This problem reported by Dave in 2002 is due to a typeinfo for the 
> exception type being emitted in each object it is used within. As 
> they are marked weak, they get coalesced into a single typeinfo *per* 
> *shared* *object* but these happily clash when multiple shared 
> objects are loaded.
>
> This then causes typeinfo comparisons to fail not because the mangled 
> symbol is different but because the addresses of each are different. 
> Dave suggested a typeinfo comparison by string and AFAICS it was 
> refused on grounds of speed (despite that comparing hashes is the 
> same speed as comparing addresses).
>
> Dave - was this problem ever fixed? 

Not AFAIK.

> If not, I will submit a patch 
> implementing typeinfo comparison by string comparison and we'll swing 
> round the roundabout once again (maybe two years of experience has 
> changed opinions).

There's a better fix that involves dealing differently with the way
the ELF loader resolves weak symbols.  You might ask Jason Merrill
(cc:'d here) about the idea - it was his.

> BTW, your problem with python having to load extension modules with 
> RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
> fvisibility=hidden patch as no symbol clashes can happen.

I don't think so; you can still have symbol clashes if two extension
modules explicitly export the same names.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com