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

[Mark Ivey]

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?

-Mark Ivey-