Open magnusjjj opened 2 years ago
Same issue here. Replacing SDL_free
with just free
also fixes it, without introducing memory leaks.
I can only imagine that older versions of SDL used to implement SDL_free
as a call to free
, and that's why it used to work in the past.
Same issue here too. It's interesting to know this SDL_free
simply refers to the C free
. There must be some bug in the SDL2.
Well, it's not a bug in SDL - it's perfectly reasonable that if a library offers its own memory management functions (SDL_malloc
, SDL_free
) that you must not mix these library functions with the standard malloc
/free
. The issue is that this project is using SDL_free
on a pointer that was allocated with regular malloc
. The allocation happens here and the deallocation here.
That's the core issue, either the allocation should be replaced with SDL_malloc
or the SDL_free
should be replaced with free
. But it happens to work by accident in case SDL_free
is implemented as regular free
, which is sometimes the case but not always, depending on how SDL is configured. It seems that newer versions of SDL on Windows do not implement SDL_free
as a call to regular free
, hence the crashes that this issue highlights. But other versions of SDL, or perhaps SDL on other platforms, might implement SDL_free
as free
and thus hide the issue.
For whatever reason, the game crashes when loading. I am compiling with Visual Studio 2022, for x64.
I hunted down the culprit in the form of:
SDL_free(fullpath);
Commenting out that in a couple of places did the trick. As to why that fixes things is an excellent question to which I don't have an answer at the moment ;).
Tried changing it to just free(fullpath); and that worked fine, not sure why the code is using SDL_free when it's not allocated by SDL, but hey. It's something.