I have three projects in my Code::Blocks workspace:
-Engine (shared object)
-Launcher (program)
-Game (shared object)

The Launcher and Game projcts both depend on the Engine to draw things, and it looks like once the Engine is loaded into memory, data seems persistent in the Engine across both projects. The engine also has a state manager built into it that processes the current game state. So, I subclass State in my Launcher program, add it to the state machine, and it works well. Then, I loaded my Game up as a shared object using dlopen(), and dlsym() from the Launcher program to hook into Game's entry-point C function I created, and that also worked. When I create a sub-class of State in my Game shared object, and use its entry-point function to add it to the engine, that works too. When I tell my engine to start using the state from my Game shared object that it now has a reference too, it'll crash with a segmentation fault when trying to run one of its overridden virtual methods as if that state is a corrupt pointer.

Sometimes, the state machine will be able to call methods from the state inside the Game shared object that was loaded manually from Launcher, and sometimes it doesn't. It's almost as if some garbage values are being used. Now sure where to go from here.

Btw, if I copy this state from Game to Launcher, and then load and switch to that state, everything runs fine. It's just when that state is in a separate shared object that's loaded at runtime.

What does your debugger tell you? Is the object null? Is the reference valid as soon as the object is created? .

My guess is the library has its own object that isn't linked up, but you really need a debugger to verify anything.

I figured out the issue. My libdl code was based around a tutorial that opened the library, got some function handles, called them, then disposed everything. Naturally, I did this, and forgot that I was disposing of my library's handles after calling my entry-point function. This explains why everything in setup works, but crashes as soon as it tries to process the library's game state in the update loop because the handle has been cleaned up. Sorry about this, I thought my edit above went through last night, when I posted it.