We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4340

Summary: SDL_SetMemoryFunctions causes heap pointer fault with custom free() function
Product: SDL Reporter: Anthony @ POW Games <ant>
Component: mainAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: sezeroz
Version: 2.0.9   
Hardware: All   
OS: Windows 10   

Description Anthony @ POW Games 2018-10-29 20:41:09 UTC 
Essentially, SDL has already used alloc() before main() is called, so a custom free() will fail.
Comment 1 Ryan C. Gordon 2018-10-30 00:01:07 UTC 
This is fixed in https://hg.libsdl.org/SDL/rev/68c87b40b434

I'm nervous about making this change right before shipping 2.0.9, so please test this!

--ryan.
Comment 2 Anthony @ POW Games 2018-10-30 00:46:59 UTC 
Can you quickly update the binaries at https://www.libsdl.org/tmp/download-2.0.php? I'm still not sure how to build from source unless I'm working with Android.
Comment 3 Sam Lantinga 2018-10-30 03:19:52 UTC 
Done!
Comment 4 Ozkan Sezer 2018-10-30 05:54:52 UTC 
SDL2-devel-2.0.9-VC.zip is not OK:  SDL2main.lib in there is outdated.
Comment 5 Anthony @ POW Games 2018-10-30 09:09:56 UTC 
Still not working when trying the latest binaries. Custom free() fails when called from main_getcmdline(). The date-stamp for SDL2main.lib didn't update, which I assume is where the fix should be?
Comment 6 Sam Lantinga 2018-10-30 13:56:11 UTC 
Right, updated now, thanks!
Comment 7 Anthony @ POW Games 2018-10-30 15:00:08 UTC 
Ok, thanks. no crashes now.

But when I put a counter in, I'm left with memory blocks not freed.

I'm only incrementing the counter when realloc is passed a non-null.

The following code causes 2 blocks to not be freed:

   SDL_Init(SDL_INIT_EVERYTHING);
   SDL_Quit();

And bizarrely the following code leaves 8 blocks not freed.

   SDL_Init(SDL_INIT_AUDIO);
   SDL_Quit();

Is this anomalous? A different issue maybe?
Comment 8 Sam Lantinga 2018-10-30 15:18:58 UTC 
Yes, this is a different issue. There are a couple places where we leak small amounts of memory because it's hard to tell when the application will actually be done with it. There might also be a legitimate bug in there as well.

Thanks!
Comment 9 Ryan C. Gordon 2018-11-01 21:37:17 UTC 
(In reply to Sam Lantinga from comment #8)
> Yes, this is a different issue. There are a couple places where we leak
> small amounts of memory because it's hard to tell when the application will
> actually be done with it. There might also be a legitimate bug in there as
> well.

This is the only one I see in loopwave.c, fwiw ...

==31490== 776 bytes in 1 blocks are still reachable in loss record 160 of 178
==31490==    at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31490==    by 0x4ED5874: SDL_malloc_REAL (SDL_malloc.c:5328)
==31490==    by 0x4ED7273: SDL_GetErrBuf (SDL_thread.c:243)
==31490==    by 0x4E590BC: SDL_ClearError_REAL (SDL_error.c:152)
==31490==    by 0x4E571C2: SDL_InitSubSystem_REAL (SDL.c:114)
==31490==    by 0x4E573C1: SDL_Init_REAL (SDL.c:256)
==31490==    by 0x4E6F65D: SDL_Init (SDL_dynapi_procs.h:85)
==31490==    by 0x108CA6: main (loopwave.c:123)

...the rest are all tiny leaks from PulseAudio, D-Bus, and dlopen() entirely beyond our control.

--ryan.
Comment 10 Sam Lantinga 2018-11-02 23:26:44 UTC 
Yup, and this memory is intentionally left allocated after SDL_Quit()