Jump to content
  • Advertisement
Sign in to follow this  
Sylveste

SDL Parachute Deployed?! (Problems with my first game project...)

This topic is 4665 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

I am using C++ & Code::Blocks & SDL (with some additional libraries) to make a simple game. I have a few C++ books under my belt and a Java programming course. I have also read alot about SDL from various sources. I have kept the code fairly simple, the game is basically and RPG which shows a pre-rendered picture of a monster and writes text like "Spider takes 3 damage." to a very simple messagebox I made with SDL_ttf. The event structure which polls for keypresses is also VERY simple. It's nearly complete now, but I ran into a problem that me (nor my more experienced friends) could not figure out... Sometimes when I run the .exe it I get the following line in stderr.txt: "Fatal signal: Segmentation Fault (SDL Parachute Deployed)" What does that mean? What ( in general) could cause something like that? The program NEVER crashes. It runs just fine, and it does not always even give this message. Even if I don't rebuild it, and run it for the second or third time it suddenly gives the message and sometimes nothing. I did not post any code yet, I'm just asking if someone has run into similar problems and found a solution, or if there's something crucial I've missed like something about the SDL Parachute :D

Share this post


Link to post
Share on other sites
Advertisement
Seg Faults are usually due to pointers that are reading/writing out-of-bounds. Usually an array or if you have a pointer that you deleted the memory from. The parachute being deployed is SDL's way of saving your proggie from a full out crash. You'll probably need to run a debugger and track any dynamic or indexing things you have in order to sniff this bugger out.

Share this post


Link to post
Share on other sites
if you init SDL with SDL_INIT_NOPARACHUTE your prgram will crash normally. the sdl parachute is there so that sdl can do some cleanup if you do crash. you may also need SDL_INIT_NOPARACHUTE to track the segfault with a debugger

good luck!

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylveste
Could it be something like that I am trying to do
SDL_FreeSurface on a surface that has been freed before?


could be. unless SDL_FreeSurface marks the surface as being free'd. try assigning NULL to your surfaces after you free them and see it it sersisits.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylveste
Could it be something like that I am trying to do
SDL_FreeSurface on a surface that has been freed before?


SDL doesn't crash on a freed surface* (it does reference counting: keeping track of whether it has been freed through SDL_Surface->refcount), nor on a NULL surface*. It does crash however on a surface* that has not been loaded or anything, I mean only declared.
Also, when I started with SDL_ttf i had some of these segfaults, it seems that that library especially is prone to segfaulting if you are not careful. The documentation describes these situations very well.
Running a debugger can tell you which lines of your code cause the problems, another way is run only parts of the program (by commenting out or something like that) to locate the problem and examine what could be the cause.

Good luck chasing those bugs.

Share this post


Link to post
Share on other sites
Get yourself the fluid studios memory manager, it's free and you compile it with your program (include the "mmgr.h" header after your normal headers).

To run it with MinGW, you will need to find the line that says something like MMGR_FUNCTION "??" and change it so the "??" becomes __func__

You also need to comment out #include "stdafx.h", and define WIN32. Look in the code for anything that says: new_handler and replace it with std::new_handler.

It should work with GCC now...

Go into mmgr.cpp, and uncomment the two tests (STRESS_TEST and the other one that's in the list). When you run your app, you should notice two files memory.log and mmgr.log (or something like that, I can't remember offhand). One should be huge - open it up and look for anything that reports an error. It should show you the function and file that casued the allocation error, you can also cross reference this reported address with the other file to see where this memory was originally allocated from. Go through and debug the code, checking for overruns, especially.

This has saved my skin a fair few times, I tell you.

Share this post


Link to post
Share on other sites
I had a line where I tried to use SDL_FreeSurface on
a surface that had been FreeSurfaced before...

I removed it and it SEEMS as though the problem has gone away...
I ran it about 10 times, even tried rebuilding it and running again...
nothing in stderr so far...

Guess that was it, then?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!