[C++-sig] boost.python changes C++ try/catch behavior?

[Roman Yakovenko]

On 1/18/07, Mark Ivey <zovirl1 at sbcglobal.net> wrote:
>
> On Jan 17, 2007, at 9:26 PM, Roman Yakovenko wrote:
>
> > On 1/18/07, Mark Ivey <zovirl at zovirl.com> wrote:
> >> I'm having a problem with exceptions which I've puzzled over the last
> >> two days, where it seems like Boost.Python is changing the behavior
> >> of try/catch and certain exceptions are slipping through the catch.
> >> I'm calling into a 3rd-party C++ library (Ogre) and trying to catch
> >> any exceptions while still in C++, like this:
> >>
> >> void load3dModel(string filename, string modelname)
> >> {
> >>      try
> >>      {
> >>          sceneManager->createEntity( modelname, filename);   // call
> >> into Ogre to load the model
> >>      }
> >>      catch(Ogre::Exception &e)   // Ogre only throws Ogre::Exception
> >>      {
> >>          cout << "Exception caught!" << endl;
> >>      }
> >> }
> >>
> >>
> >> If I call load3dModel() from a C++ program, exceptions are caught
> >> correctly.  However, if I call load3dModel() from a boost.python
> >> wrapper, certain exceptions* are not caught in C++ and I get "Runtime
> >> Error: unidentifiable C++ exception."  If I change the catch to be
> >> catch(...) then everything is caught correctly when using
> >> boost.python.  So, why aren't the exceptions being caught by catch
> >> (Ogre::Exception &e)?  Why does using Boost.Python allow them to slip
> >> through?
> >>
> >> * specifically, exceptions thrown from dynamically-loaded C++ plugins
> >> are not caught when running with boost.python.  Exceptions from the
> >> core Ogre library are still caught.
> >>
> >> I've searched google and found nothing.  I've tried to pare down the
> >> code to a minimal example to isolate the problem, but I can't
> >> reproduce the problem without calling into Ogre.  If I call my own
> >> code, the exceptions are always caught.  I ran everything under GDB
> >> but didn't find anything useful.  I don't know what else to try.  Any
> >> suggestions would be appreciated.
> >>
> >> This is on Ubuntu Linux 6.04, with g++ 4.0.3, boost python 1.33.1,
> >> Ogre 1.2.  I can post any other info you might want, I'm just not
> >> sure what else is relevant.
> >
> > Try this ( from Python documentation )
> >
> > setdlopenflags(n)
> >    Set the flags used by the interpreter for dlopen() calls, such as
> > when the interpreter loads extension modules. Among other things, this
> > will enable a lazy resolving of symbols when importing a module, if
> > called as sys.setdlopenflags(0). To share symbols across extension
> > modules, call as sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL).
> > Symbolic names for the flag modules can be either found in the dl
> > module, or in the DLFCN module. If DLFCN is not available, it can be
> > generated from /usr/include/dlfcn.h using the h2py script.
> >
> > setdlopenflags function belongs to sys module. I think this should
> > solve your problem.
>
> Yes, it did.  Thanks!  Is there a reason this isn't the default?
> i.e. are the times when it wouldn't be appropriate to set those flags?

I don't know.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/