Jump to content

  • Log In with Google      Sign In   
  • Create Account

Seg Fault When Modifying Data Across a Shared Object


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Vincent_M   Members   -  Reputation: 744

Like
0Likes
Like

Posted 06 March 2014 - 02:59 AM

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.

Sponsor:

#2 frob   Moderators   -  Reputation: 22709

Like
0Likes
Like

Posted 06 March 2014 - 10:31 AM

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.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 KnolanCross   Members   -  Reputation: 1361

Like
1Likes
Like

Posted 06 March 2014 - 11:00 AM

Have you tried running in debug mode (Default to F8)? You will get a GDB trace (you can use the console to manually enter commands or an interface in the left part of the screen).

 

Also, have you tried running it on valgrind?


Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).


#4 Bregma   Crossbones+   -  Reputation: 5426

Like
0Likes
Like

Posted 06 March 2014 - 11:15 AM

The symptoms you describe sound not unlike an ABI break.  Have you tried cleaning and rebuilding the entire project?


Stephen M. Webb
Professional Free Software Developer

#5 Vincent_M   Members   -  Reputation: 744

Like
0Likes
Like

Posted 06 March 2014 - 09:15 PM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS