Jump to content

  • Log In with Google      Sign In   
  • Create Account

Segfault upon exiting application


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
6 replies to this topic

#1 chiranjivi   Members   -  Reputation: 197

Like
0Likes
Like

Posted 26 July 2014 - 02:31 PM

I'm working on a project at the moment in CodeBlocks using SDL2. At some point during development (I'm not exactly sure when tongue.png) the application began to segfault upon closing down.

 

If I set a breakpoint somewhere and step through the code line-by-line, the crash doesn't happen until after the app successfully executes return 0; at the end of int main, so I don't know where I should be looking for the error.

 

When the segfault occurs, the console output usually reads "Process returned 255 (0xFF)", although I infrequently get "Process returned -1073741819 (0xC0000005)" instead, seemingly at random. 0xC0000005 as far as I can tell means it is accessing memory it shouldn't?

 

Here's a screenshot of the call stack:

 

wRSVm8h.png

 

I would post some code, but I have no idea what code might actually be relevant and the project is very large. I would welcome any insight here as I have no idea what is going on! Thanks in advance for any replies.

 

edited to add: apologies if this question would be better suited for a different subforum, I didn't really know where to put it


Edited by chiranjivi, 26 July 2014 - 02:32 PM.


Sponsor:

#2 Paradigm Shifter   Crossbones+   -  Reputation: 5380

Like
2Likes
Like

Posted 26 July 2014 - 02:34 PM

C++? Check your destructors of global objects, they run after main returns.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#3 chiranjivi   Members   -  Reputation: 197

Like
0Likes
Like

Posted 26 July 2014 - 03:56 PM

C++? Check your destructors of global objects, they run after main returns.

 

Ah, yeah that seems like it would be it. I recently made an abstract class from which the player and the enemies derive so that they can share common functions, and the player object is global for the sake of convenience. What issue with the destructors is this causing? (Despite now knowing where the problem lies I'm still not sure how I can fix it).

 

Thanks for your help.



#4 Paradigm Shifter   Crossbones+   -  Reputation: 5380

Like
2Likes
Like

Posted 26 July 2014 - 03:58 PM

Deleting something twice, accessing objects that have been destroyed, that kind of thing
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#5 aregee   Members   -  Reputation: 1025

Like
0Likes
Like

Posted 26 July 2014 - 06:21 PM

I was going to suggest the same thing as the posters above, but I might add a question if you are doing any kind of multi tasking or something?  Freeing resources for a task that hasn't stopped processing or something?



#6 Karsten_   Members   -  Reputation: 1611

Like
0Likes
Like

Posted 28 July 2014 - 03:50 AM

I dont know if it helps but one of the students I have been taking lab sessions for at the Uni was attempting to use SDL_FreeSurface() on the SDL_Surface* returned from SDL_SetVideoMode(). This was the reason for a crash during exit.

This was incorrect and this SDL_Surface* is cleaned up when SDL_Quit() is called instead.

So perhaps you have put this SDL_FreeSurface as a deleter in a unique_ptr / shared_ptr and is causing a double delete issue when exiting.

Edited by Karsten_, 28 July 2014 - 03:50 AM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#7 frob   Moderators   -  Reputation: 21475

Like
1Likes
Like

Posted 28 July 2014 - 06:25 AM

What issue with the destructors is this causing? (Despite now knowing where the problem lies I'm still not sure how I can fix it)

The same way you find and fix invalid pointers elsewhere.

Usually the easiest is to catch it in a debugger or to generate a crash dump and review it.

With it open in the debugger, look at the call stack at the time of the crash. Something told the program to look at that location. Since it is after main() returned, it is possibly a destructor or some code called by a destructor or possibly code registered to be run by atexit() or some other method.

Often in the debugger you can discover the exact line number of the function that dereferenced the memory, other times you just get the function names. Occasionally you will just get a memory region that requires looking it up in the executable's map file. Rarely you will have corrupted your stack or other memory to the point where you cannot identify the location, and then you have a nightmare debugging scenario far beyond the scope of a forum post. If know the exact instruction within a line, identifying the pointer is done for you, it is the pointer listed in the instruction. If you know the line, look for all the potential pointers that could be followed. If it is a full function, look for all the potential pointers in the function as well as any calls that are made within the function.

Usually the process is very quick. Most often it is just an object that has been destroyed but either wasn't zeroed out after destruction, or a dangling reference to something. Occasionally it is a different problem, like an overwritten memory buffer.

Anyway, once you find it, eliminate it. If the pointer was previously zeroed out, just add a null check and verify the solution. If the pointer wasn't zeroed out, search the code for all the places that can potentially release that piece of memory and make sure they zero it out after release, and still add the null check; then verify the solution.

EDIT: Since you helpfully provided some info from your call stack, the isspace() and the open() suggest it is something dealing with a file stream cleanup. Pick those functions in the debugger, see what they are and what they contain. The open() function looks like it is very near your main function, so it should provide a convenient place to backtrack from.
Check out my personal indie blog at bryanwagstaff.com.




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