Closed matthiaskrgr closed 6 years ago
Thanks a lot for pointing this out. Indeed, this game (coming from the stone age) didn't really bother with freeing any memory at exit, and left this for the OS. This isn't a big issue, but I thought it's indeed better to remove those, it's cleaner and should help finding actual leaks and other problems.
@matthiaskrgr btw, what tool are you using for finding memory leaks? I'm running valgrind, but that also produces lots of spurious stuff, such a leaks in the system library and SDL.
I'm using the address sanitizer https://clang.llvm.org/docs/AddressSanitizer.html#id7
just build with -fsanitize=address
cflag and run the game. It will show the leaks on exit.
that's awesome, thanks for the hint, looks like a very nice tool.
Yes, it already helped me found tens of bugs in various programs/games :)
Note that you can also combine address and undefined behaviour sanitizer
-fsanitize=address,undefined
(UBSan is how I found the zeroDiv in https://github.com/ReinhardPrix/FreedroidClassic/issues/8 )
-g3 -Og -fsanitize=address,undefined -fno-omit-frame-pointer -fno-optimize-sibling-calls
is usually a good setup to detect such bugs (run with export UBSAN_OPTIONS=print_stacktrace=1
for ubsan-runtime backtraces)
You can get more info on the sanitizer runtime configurations with ASAN_OPTIONS=help=1 ./freedroid
and UBSAN_OPTIONS=help=1 ./freedroid
respectively.
Sorry, there was some miscommunication, when I meant that the other memleaks underlated to the editor still exist.
Maybe the ticket was not detailed enough.
These memleaks can be reproduced by just starting up the game and terminating it through the main menu: