Sign in to follow this  

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

This topic is 4360 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
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
Quote:
Original post by evolutional
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.


Wow, this is really nice. I don't mean to hijack this thread, but one question if I may. I can get it to work, though the log says for example "00001 new of size 0x0000002B(00000043) by ??(00000)::??". I guess it isn't able to get the function name. (I did change #define __FUNCTION__ "??" to #define __FUNCTION__ __func__). Any thoughts on where i should look? Thanx.

Share this post


Link to post
Share on other sites

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