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

Niall Douglas s_sourceforge at nedprod.com
Fri Jul 9 20:21:54 CEST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8 Jul 2004 at 21:24, Ralf W. Grosse-Kunstleve wrote:

> --- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> > 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.
> 
> Hi Niall,
> 
> I don't use embedding, so I am not sure this is relevant, but ever
> since I started importing all extension modules with RTLD_GLOBAL under
> Linux I've not observed exception handling problems anymore. I.e. I am
> doing the exact opposite of what I understand you are suggesting
> above. Here is my trick, the "import_ext" function:

Just to clarify, Dave in his original post said that Python needed to 
use RTLD_LOCAL to prevent symbols in multiple extension modules from 
clashing. This however comes with many downsides, including breaking 
static variables and loads of other bad things. I was suggesting that 
if you use -fvisibility=hidden then no symbols are exported from any 
extension modules at all (apart from the minimum which you will 
ensure are unique) so Python can use RTLD_GLOBAL again which solves 
many other problems.

> http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/boost/python
> .py?view=markup
> 
> Does it make sense to you that this approach seems to fix the EH
> problems? (Or am I just lucky? Hope not.)

I assume 0x100|0x2 means RTLD_GLOBAL. Well, since python extension 
modules have no reason to throw a C++ exception into python you're 
probably fairly safe. The issues begin when ld.so loads a so due to 
dependency requirements of a previous so which then causes the 
merging of symbols to come out with different addresses so typeinfo 
comparisons magically fail.

With a bit of work, the shared library system on Linux can be made to 
play nice with C++. I'm kinda surprised it wasn't done already as I'd 
have thought people would be clamouring for it but if they didn't 
before, now GCC 3.4 is so standards compliant they surely will in the 
future.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQO7iQsEcvDLFGKbPEQIElwCfcZJ9Q25bwj7kt79P/oxoWo0MBTwAoLZA
VOW8RoeTT1AWhMOgxB909H5A
=BX0l
-----END PGP SIGNATURE-----



More information about the Cplusplus-sig mailing list