I'm rewriting a game from C++ to C just for the purpose of learning and adding more features, however; after I refactored the code, the game broke with a segmentation fault and I have no idea where the memory issue is.

I've been debugging for hours now and I've got nothing. FML

GDB (GNU Debugger) is great here. Just setting a signal catch on SIGSEGV should already get you further. See also here: http://unknownroad.com/rtfm/gdbtut/...

You may also try CppCheck, sometimes it finds fishy parts that have slipped past -Wall -Wextra with GCC (you are using max warning level?).

Valgrind could also come in handy, if memory serves.

Actually, now that I think of it, Valgrind is particularly handy when memory is NOT serving ...

@Fast-Nop I was compiling with `-Wall` flag but added `-Wextra` today and found some more warnings. However, I ran the game today and, weird enough, the issue is gone and I couldn't replicate it!

Also, I was using GDB to debug but I didn't know about some of the commands in the link so thanks a lot, it's very useful.

@andros705 @catadoxa Thanks guys, the issue is resolved, I guess.

@rantsauce things that crash sometimes and suddenly stop doing so may be uninitialised variables where it depends on memory garbage whether it works or not.

Another thing is memory you alloc via malloc (not calloc). If your process gets memory the first time, it is zeroed by the OS to prevent you from reading other processes' data. If you release that memory and alloc it again, there can be your own garbage inside. In such a case, the program can run at first, but suddenly stop doing so.

I would avoid malloc and use calloc unless benchmarking has shown that this is a performance issue - and in that case, I'd eliminate the whole dealloc/realloc thing because then it's even faster.