[C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
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::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::_bi::list3, boost::arg<2>, boost::_bi::value > >, bool, boost::python::detail::exception_handler const&, boost::function0 const&>::invoke () from /usr/local/lib/python2.6/site-packages/mapnik/64/_mapnik.so #10 0xfd7ff3aa2e25 in boost::python::handle_exception_impl () from /usr/local/lib/libboost_python.so.1.44.0 #11 0xfd7ff3a97d50 in function_call () from /usr/local/lib/libboost_python.so.1.44.0 #12 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #13 0xfd7ff700af29 in instancemethod_call () from /usr/lib/amd64/libpython2.6.so.1.0 #14 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #15 0xfd7ff705d8a1 in slot_tp_init () from /usr/lib/amd64/libpython2.6.so.1.0 #16 0xfd7ff7051c06 in type_call () from /usr/lib/amd64/libpython2.6.so.1.0 #17 0xfd7ff6ff9aad in PyObject_Call () from /usr/lib/amd64/libpython2.6.so.1.0 #18 0xfd7ff709c1c0 in do_call () from /usr/lib/amd64/libpython2.6.so.1.0 #19 0xfd7ff709b672 in call_function () from /usr/lib/amd64/libpython2.6.so.1.0 #20 0xfd7ff709810d in PyEval_EvalFrameExReal () from /usr/lib/amd64/libpython2.6.so.1.0 #21 0xfd7ff7094d9d in PyEval_EvalFrameEx () from /usr/lib/amd64/libpython2.6.so.1.0 #22 0
Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
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::list3, boost::arg<2>, > boost::_bi::value > >, bool, > boost::python::detail::exception_handler const&, boost::function0 > const&>::invoke () > from /usr/local/lib/python2.6/site-packages/mapnik/64/_mapnik.so > #10 0xfd7ff3aa2e25 in boost::python::handle_exception_impl () from > /usr/local/lib/libboost_python.so.1.44.0 > #11 0xfd7ff3a97d50 in function_call () from > /usr/local/lib/libboost_python.so.1.44.0 > #12 0xfd7ff6ff9aad in PyObject_Call () from > /usr/lib/amd64/libpython2.6.so.1
Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
On 12/02/2010 02: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? I'm not running Solaris, so I can't help too much specifically, but it sounds like you might learn a lot from trying exceptions in a non-Boost Python module compiled in C++. Perhaps just take the first example here: http://docs.python.org/extending/ and add a function that throws and catches an exception. If that succeeds, try throwing and catching in a shared library that's linked to your Python module, and then try throwing and catching across the library boundary. You might also want to check the compile flags for Python itself, just in case there's something obviously different there between 64-bit and 32-bit on Solaris. Good luck! Jim Bosch ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] help finding solution to lack of exception handling with boost python on open solaris 64 bit
In the early days (~2002) we had trouble with EH on some Linux platforms, too. One workaround that helped for some things was to catch exceptions in the same .so where they were raised (e.g. boost::python::throw_error_already_set() ensures the exception is thrown in the libboost_python.so). Similar to Jim's suggestion, I'd try to find out if this is also your problem. In the worst case I'd combine all extensions into one (assuming you have multiple). Another option is to try different dlopen flags, e.g. sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL) Ralf - Original Message > From: Dane Springmeyer > To: Development of Python/C++ integration > Cc: mapnik-devel > Sent: Thu, December 2, 2010 2:23:02 PM > Subject: [C++-sig] help finding solution to lack of exception handling with >boost python on open solaris 64 bit > > 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_invoker2boost::python::detail::translate_exception(*)(std::exception const&)>, boost::_bi::list3, boost::arg<2>, >boost::_bi::value > >, bool, >boost::python::detail
