Sign in to follow this  

Catching Exceptions from Dynamically Loaded Shared Objects

This topic is 3596 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Wow, this is about the fourth post in a row I've made about pretty much the same topic! Sorry, everyone! :-P Anyway, I'm having some more shared object woes. At the time being, I'm using the ld library on a Linux system to handle dynamically loading a shared object that implements a module for my game engine. I plan to use the tentative Boost.Extension and Boost.Reflection, but that project is still not official and is in its early stages, I believe. Anyway, I noticed that during a test that my test program suddenly stopped and closed. It didn't explode, but rather exited cleanly, with destructors doing their work like they're supposed to. Puzzled, I added some more output and discovered that whenever I threw an exception from within the module (my dynamically loaded shared object) I could never catch it from within the main executable! My question is, is there a way to get this to work? If so, is it relatively clean, or would I need to depend on platform/compiler specific tools/libraries? Am I better off communicating errors from a module via flags and return codes? I decided a long time ago that I wanted to opt to use exceptions in my engine, so if possible that's what I'd like to do so long as the solution is cross platform. If modules have to use error codes, that isn't such a big deal since the core can just throw an exception in response. Just so it's a bit more clear, here's what things look like; I know I'm being a bit ambiguous.
Client Program ---shared object, linked to client---> Mocha ---shared object, loaded at runtime---> Guarana
Mocha is the name of the engine and is the core. Guarana is my default implementation that provides access to all sorts of functionality Mocha needs (graphics, input, audio, etc.). The test (client) program is linked to Mocha as usual, and Mocha dynamically loads Guarana at runtime. That's where my problems begin. I've mentioned this in other posts, but I've also found that I cannot use boost::shared_ptr objects (and therefore boost::signal objects) between Mocha and Guarana due to this runtime loading. I'm passing the bits RTLD_NOW | RTLD_DEEPBIND | RTLD_GLOBAL to dlopen(). I'm not sure if that's helpful. Any help, insight, or suggestions into this issue are greatly appreciated. Thanks! :-)

Share this post


Link to post
Share on other sites
I've had absolutely no luck getting this to work regardless of my g++ options. However, by having Mocha expose a function to throw an exception, Guarana can now throw exceptions that can be caught by a client program! I have to admit that this confuses me a bit, since the function is called from the dynamically loaded shared object, but after some testing it seems quite reliable.

the only problem with this method is limiting the types of exceptions that modules can throw, but I don't think that's ultimately a big deal since exceptions thrown from a module (that aren't somehow handled by Mocha) are pretty serious.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
I dont have much experience with Linux, but in general, you're not supposed to throw an exception across a "program boundary", such as from a dynamic library.


This is pretty much what I figured when I first encountered this problem (which reflects the issues with boost::shared_ptr as well since I believe the reference counting mechanisms don't work across this border).

The only other solution I see is to have functions in the module use flags and error codes and have Mocha examine them and throw accordingly. Exposing that exception throwing function seems to work though; I'm just not sure yet if it's a fluke and is primed and ready to explode.

Any ideas about this?

Share this post


Link to post
Share on other sites

This topic is 3596 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this