Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
Have you checked to ensure your applications meet the criteria specified in http://www.nedprod.com/programs/gccvisibility.html? Usually this problem is due to a failure to fully implement this. Or it's a bug in GCC :) Niall On 2 Dec 2010 at 18:05, Charles Solar wrote: > This happens in my application as well, dont know if its a known issue for > boost python or not.. > I too would like to see a solution; I myself have not had anytime to look > into it since exceptions are a rare thing in my app. > I can confirm however that a similar problem occurs on Solaris Sparcv9 > machines, so I am guessing it has something to do with how solaris handles > 64 bit exception handling. Something boost is not setup to handle I would > suppose. > > Charles > > On Thu, Dec 2, 2010 at 4:23 PM, Dane Springmeyer wrote: > > > Hello, > > > > I recently recompiled my C++ app (mapnik.org, which uses boost python for > > python binding) with -m64 flags for 64 bit operation and this broke the > > boost python exception handling. > > > > Instead of C++ exceptions being propagated to python exceptions, I get > > segmentation faults (core dump). > > > > I have a long dependency chain that all needs to be 64 bit, so I'm really > > stuck unless I can find a way to restore boost python's ability to handle > > exceptions without crashing. > > > > Exceptions are very common during setup of mapnik, and are needed to report > > basic configuration issues as a user gets set up. > > > > I'm desperate to try anything that might help - anyone have any > > suggestions? > > > > What i have tried so far: > > > > 1) recompiling all apps with -02 instead of -03 > > 2) making sure all apps are compiled with the exact same version of gcc (at > > least all the C++ libraries I have compiled from source) > > 3) ensured that all dynamic libraries link to the same libgcc_s.so.1 and > > libstdc++.so.6. > > 4) tried with both boost 1.44 and 1.45 > > > > I'm out of ideas - anyone have suggestions to try? > > > > More info below. > > > > Dane > > > > -- > > > > With 32bit boost, python, and mapnik, exceptions worked fine. > > > > This is on opensolaris: > > > > $ cat /etc/release > > OpenSolaris Development snv_133 X86 > > Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. > > Use is subject to license terms. > > Assembled 15 February 2010 > > > > with the sun provided 64 bit python26: > > > > $ /usr/bin/amd64/python --version > > Python 2.6.4 > > > > Both boost and mapnik are compiled with a *custom* compiled gcc 44: > > > > $ /opt/ts/gcc/4.4/bin/g++ -v > > Using built-in specs. > > Target: i386-pc-solaris2.11 > > Configured with: .././configure --prefix=/opt/ts/gcc/4.4 > > --bindir=/opt/ts/gcc/4.4/bin --libdir=/opt/ts/gcc/4.4/lib > > --mandir=/opt/ts/gcc/4.4/share/man --datadir=/opt/ts/gcc/4.4/share > > --includedir=/opt/ts/gcc/4.4/include --infodir=/opt/ts/gcc/4.4/share/info > > --libexecdir=/opt/ts/gcc/4.4/lib --sysconfdir=/etc/opt/ts --disable-nls > > --disable-static --with-gnu-as --with-as=/usr/gnu/bin/as --without-gnu-ld > > --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared > > --enable-multilib --enable-nls --without-x --with-system-zlib > > --enable-languages=c,c++,f95,objc --with-mpfr=/opt/ts --with-gmp=/opt/ts > > Thread model: posix > > gcc version 4.4.4 (GCC) > > > > ( I was unable to get boost compiled with the gcc 3.4.3 or gcc 4.3.3 > > provided by sun packages, for more info see: > > http://trac.mapnik.org/wiki/OpenSolarisInstallation/TroubleShooting) > > > > > > So, instead of throwing an understandable exception, boost python crashes > > and this is what a normal backtrace looks like in gbd: > > > > (gdb) bt > > #0 0x0005f666 in ?? () > > #1 0xfd7fff2ec5d1 in _Unwind_RaiseException_Body () from > > /usr/lib/amd64/libc.so.1 > > #2 0xfd7fff2ec855 in _Unwind_RaiseException () from > > /usr/lib/amd64/libc.so.1 > > #3 0xfd7ffa98bb39 in __cxa_throw (obj=, > > tinfo=0x1, dest=0x474e5543432b2b00) > > at ../../../../.././libstdc++-v3/libsupc++/eh_throw.cc:78 > > #4 0xfd7ff3aa2de2 in boost::python::throw_error_already_set () from > > /usr/local/lib/libboost_python.so.1.44.0 > > #5 0xfd7ff3a9ae31 in boost::python::objects::function::argument_error > > () from /usr/local/lib/libboost_python.so.1.44.0 > > #6 0xfd7ff3a9b4fb in boost::python::objects::function::call () from > > /usr/local/lib/libboost_python.so.1.44.0 > > #7 0xfd7ff3a9b730 in > > boost::detail::function::void_function_ref_invoker0 > namespace)::bind_return, void>::invoke () from > > /usr/local/lib/libboost_python.so.1.44.0 > > #8 0xfd7ff3aa3053 in > > boost::python::detail::exception_handler::operator() () from > > /usr/local/lib/libboost_python.so.1.44.0 > > #9 0xfd7ff28fb1b2 in > > boost::detail::function::function_obj_invoker2 > boost::python::detail::translate_exception > (*)(std::exception const&)>, boost::_bi
Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
Thanks everyone for your ideas! Exactly what I was looking for.
With your help I I've narrowed it down to duplicate libgcc_s.so versions being
imported, as this solves it:
LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so
So I can now do:
LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so /usr/bin/amd64/python -c "import
mapnik;mapnik.Map('this should throw exception');"
...which now throws a proper argument error exception.
So, my error is now clearer: I've been using sun provided 64 bit python
compiled with a different gcc version than I built both boost and mapnik with.
Why I could get away with this in 32 bit mode is beyond me.
My understanding is that by using LD_PRELOAD I am able to force the libgcc_s.so
version that python itself is linked to - to be loaded first (rather than the
libgcc_s.so that boost_python and _mapnik.so are linked to). This allows both
the exception handling to work again and the program (surprisingly) to run
properly (tests pass at least).
I figure, since I was unable to compile boost_python (or boost proper) with the
gcc version from sun (and that the sun python was compiled with), my only
proper route from here is to compile python myself using my custom version of
gcc.
Dane
>>
>> On Thu, Dec 2, 2010 at 4:23 PM, Dane Springmeyer wrote:
>>
>>> Hello,
>>>
>>> I recently recompiled my C++ app (mapnik.org, which uses boost python for
>>> python binding) with -m64 flags for 64 bit operation and this broke the
>>> boost python exception handling.
>>>
>>> Instead of C++ exceptions being propagated to python exceptions, I get
>>> segmentation faults (core dump).
>>>
>>> I have a long dependency chain that all needs to be 64 bit, so I'm really
>>> stuck unless I can find a way to restore boost python's ability to handle
>>> exceptions without crashing.
>>>
>>> Exceptions are very common during setup of mapnik, and are needed to report
>>> basic configuration issues as a user gets set up.
>>>
>>> I'm desperate to try anything that might help - anyone have any
>>> suggestions?
>>>
>>> What i have tried so far:
>>>
>>> 1) recompiling all apps with -02 instead of -03
>>> 2) making sure all apps are compiled with the exact same version of gcc (at
>>> least all the C++ libraries I have compiled from source)
>>> 3) ensured that all dynamic libraries link to the same libgcc_s.so.1 and
>>> libstdc++.so.6.
>>> 4) tried with both boost 1.44 and 1.45
>>>
>>> I'm out of ideas - anyone have suggestions to try?
>>>
>>> More info below.
>>>
>>> Dane
>>>
>>> --
>>>
>>> With 32bit boost, python, and mapnik, exceptions worked fine.
>>>
>>> This is on opensolaris:
>>>
>>> $ cat /etc/release
>>> OpenSolaris Development snv_133 X86
>>> Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
>>> Use is subject to license terms.
>>> Assembled 15 February 2010
>>>
>>> with the sun provided 64 bit python26:
>>>
>>> $ /usr/bin/amd64/python --version
>>> Python 2.6.4
>>>
>>> Both boost and mapnik are compiled with a *custom* compiled gcc 44:
>>>
>>> $ /opt/ts/gcc/4.4/bin/g++ -v
>>> Using built-in specs.
>>> Target: i386-pc-solaris2.11
>>> Configured with: .././configure --prefix=/opt/ts/gcc/4.4
>>> --bindir=/opt/ts/gcc/4.4/bin --libdir=/opt/ts/gcc/4.4/lib
>>> --mandir=/opt/ts/gcc/4.4/share/man --datadir=/opt/ts/gcc/4.4/share
>>> --includedir=/opt/ts/gcc/4.4/include --infodir=/opt/ts/gcc/4.4/share/info
>>> --libexecdir=/opt/ts/gcc/4.4/lib --sysconfdir=/etc/opt/ts --disable-nls
>>> --disable-static --with-gnu-as --with-as=/usr/gnu/bin/as --without-gnu-ld
>>> --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared
>>> --enable-multilib --enable-nls --without-x --with-system-zlib
>>> --enable-languages=c,c++,f95,objc --with-mpfr=/opt/ts --with-gmp=/opt/ts
>>> Thread model: posix
>>> gcc version 4.4.4 (GCC)
>>>
>>> ( I was unable to get boost compiled with the gcc 3.4.3 or gcc 4.3.3
>>> provided by sun packages, for more info see:
>>> http://trac.mapnik.org/wiki/OpenSolarisInstallation/TroubleShooting)
>>>
>>>
>>> So, instead of throwing an understandable exception, boost python crashes
>>> and this is what a normal backtrace looks like in gbd:
>>>
>>> (gdb) bt
>>> #0 0x0005f666 in ?? ()
>>> #1 0xfd7fff2ec5d1 in _Unwind_RaiseException_Body () from
>>> /usr/lib/amd64/libc.so.1
>>> #2 0xfd7fff2ec855 in _Unwind_RaiseException () from
>>> /usr/lib/amd64/libc.so.1
>>> #3 0xfd7ffa98bb39 in __cxa_throw (obj=,
>>> tinfo=0x1, dest=0x474e5543432b2b00)
>>> at ../../../../.././libstdc++-v3/libsupc++/eh_throw.cc:78
>>> #4 0xfd7ff3aa2de2 in boost::python::throw_error_already_set () from
>>> /usr/local/lib/libboost_python.so.1.44.0
>>> #5 0xfd7ff3a9ae31 in boost::python::objects::function::argument_error
>>> () from /usr/local/lib/libboost_python.so.1.44.0
>>> #6 0xfd7ff3a9b4fb in boost::python::objects::function::call () from
>>> /usr/local/lib/libboost_python.so.1.
