[C++-sig] Re: Multiple typeinfos causing failure of exception catches
dave at boost-consulting.com
Fri Jul 9 14:36:56 CEST 2004
"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:
> 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?
> 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.
More information about the Cplusplus-sig