Question

I'm currently working on a game with a plugin based architecture. The executable consists mostly of a shared library loader and a couple of interface definitions. All the interesting stuff is happening in dynamic shared libraries which are loaded at start up.

One of the library classes throws an exception under certain circumstances. I would expect to be able to catch this exception and do useful stuff with it but this is where it gets weird. See following simplified example code:

main.cpp

int main()
{
  try
  {
    Application app;
    app.loadPlugin();
    app.doStuffWithPlugin();
    return 0;
  }
  catch(const std::exception& ex)
  {
     // Log exception
     return 1;
  }
}

Application.cpp

...
void doStuffWithPlugin()
{
  plugin.doStuff();
}
...

Plugin.cpp

...
void doStuff()
{
   throw exception_derived_from_runtime_error("Something is wrong");
}
...

Plugin.cpp exists in a dynamic shared library which is successfully loaded and which has afterwards created an object of class Plugin. The exception_derived_from_runtime_error is defined in the application. There is no throw() or noexcept.

I would expect to catch the exception_derived_from_runtime_error in main but that doesn't happen. Compiled with GCC 4.8 using C++11 the application crashes with This application has requested the Runtime to terminate it in an unusual way..

I replaced catch(const std::exception& ex) with catch(...) but that didn't make any difference. The weird part is if i catch the exception in doStuffWithPlugin() it works. If i rethrow it using throw; it fails again but it can be caught if i use throw ex;:

Application.cpp

void doStuffWithPlugin()
{
  try
  {
      plugin.doStuff();
  }
  catch(const exception_derived_from_runtime_error& ex)
  {
     // throw; <- Not caught in main().
     // throw ex; <- Caught in main().
  }
}

Hopefully somebody has an idea. Thanks for every help you can give.

Était-ce utile?

La solution

As mentioned in the comments this seems to be a problem with shared libraries on Windows. The behavior occurs if the library is unloaded and an object created in this libraries remains in memory. The application seems to crash immediately. The only reference to this problems are found if gcc as an cross compiler or MinGW is used. See also https://www.sourceware.org/ml/crossgcc/2005-01/msg00022.html

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top