This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Windows 10, All

Comments on the original bug report:

On 2018-10-29 20:41:09 +0000, Anthony @ POW Games wrote:

Essentially, SDL has already used alloc() before main() is called, so a custom free() will fail.

On 2018-10-30 00:01:07 +0000, Ryan C. Gordon wrote:

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.

On 2018-10-30 00:46:59 +0000, Anthony @ POW Games wrote:

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.

On 2018-10-30 03:19:52 +0000, Sam Lantinga wrote:

Done!

On 2018-10-30 05:54:52 +0000, Ozkan Sezer wrote:

SDL2-devel-2.0.9-VC.zip is not OK: SDL2main.lib in there is outdated.

On 2018-10-30 09:09:56 +0000, Anthony @ POW Games wrote:

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?

On 2018-10-30 13:56:11 +0000, Sam Lantinga wrote:

Right, updated now, thanks!

On 2018-10-30 15:00:08 +0000, Anthony @ POW Games wrote:

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?

On 2018-10-30 15:18:58 +0000, Sam Lantinga wrote:

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!

On 2018-11-01 21:37:17 +0000, Ryan C. Gordon wrote:

(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.

On 2018-11-02 23:26:44 +0000, Sam Lantinga wrote:

Yup, and this memory is intentionally left allocated after SDL_Quit()