This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-10-30 22:31:21 +0000, Alex wrote:

I tested it with SDL2 from HG (HG version 5302aee2916a).
I made test program, which only init and deinit (quit) SDL library, like this:

#include "SDL.h"
int main(void)
{
SDL_Init(0);
SDL_Quit();
return 0;
}

Then I tested it with valgrind and this is log:

==27669== HEAP SUMMARY:
==27669== in use at exit: 864 bytes in 2 blocks
==27669== total heap usage: 2 allocs, 0 frees, 864 bytes allocated
==27669==
==27669== 88 bytes in 1 blocks are still reachable in loss record 1 of 2
==27669== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27669== by 0x4C2B857: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27669== by 0x4EAAC9A: SDL_TLSSet_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x4EAAFA3: SDL_GetErrBuf (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x4E4E1C8: SDL_ClearError_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x4E4CF15: SDL_InitSubSystem_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x400651: main (main.c:7)
==27669==
==27669== 776 bytes in 1 blocks are still reachable in loss record 2 of 2
==27669== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27669== by 0x4EAAFAD: SDL_GetErrBuf (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x4E4E1C8: SDL_ClearError_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x4E4CF15: SDL_InitSubSystem_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.0)
==27669== by 0x400651: main (main.c:7)
==27669==
==27669== LEAK SUMMARY:
==27669== definitely lost: 0 bytes in 0 blocks
==27669== indirectly lost: 0 bytes in 0 blocks
==27669== possibly lost: 0 bytes in 0 blocks
==27669== still reachable: 864 bytes in 2 blocks
==27669== suppressed: 0 bytes in 0 blocks

As you can see 864 bytes in 2 blocks still reachable. Is it possible to fix this leaks? Please fix it if you can.

On 2014-11-02 16:13:40 +0000, Philipp Wiesemann wrote:

The leaked memory is used by the buffered SDL error data structure and the TLS data structure holding it for the main thread. SDL does not clean up this TLS on application ends. This means that for no data the added destructor functions are called which would be the actual bug because they would have freed this memory.

On 2015-02-19 05:22:23 +0000, Ryan C. Gordon wrote:

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

On 2015-04-06 15:22:13 +0000, Ryan C. Gordon wrote:

(In reply to Philipp Wiesemann from comment # 1)

The leaked memory is used by the buffered SDL error data structure and the
TLS data structure holding it for the main thread. SDL does not clean up
this TLS on application ends. This means that for no data the added
destructor functions are called which would be the actual bug because they
would have freed this memory.

Yeah, this is kind of hard to fix. Threads call their TLS destructor while shutting down, but the main thread can't really do that unless we install an atexit() handler (and what's the point of an atexit() handler that frees memory?).

TLS is meant to remain viable after SDL_Quit(), I suppose, and SDL_Quit() might be called on something other than the main thread anyhow.

I guess we could suppress this in Valgrind...?

--ryan.

On 2015-04-06 16:53:01 +0000, Ryan C. Gordon wrote:

Anyhow, I'm going to remove this from the 2.0.4 todo list. We'll figure it out later, I hope.

--ryan.

On 2020-03-25 00:25:29 +0000, Ryan C. Gordon wrote:

Consolidating this with Bug # 5041.

*** This bug has been marked as a duplicate of bug 5041 ***