I'm working on a project at the moment in CodeBlocks using SDL2. At some point during development (I'm not exactly sure when ) 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:

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

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.

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?

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.