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 2771 - Memory leaks in SDL init/deinit
Summary: Memory leaks in SDL init/deinit
Status: RESOLVED DUPLICATE of bug 5041
Alias: None
Product: SDL
Classification: Unclassified
Component: thread (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-30 22:31 UTC by Alex
Modified: 2020-03-25 00:25 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2014-10-30 22:31:21 UTC 
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.
Comment 1 Philipp Wiesemann 2014-11-02 16:13:40 UTC 
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.
Comment 2 Ryan C. Gordon 2015-02-19 05:22:23 UTC 
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!
Comment 3 Ryan C. Gordon 2015-04-06 15:22:13 UTC 
(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.
Comment 4 Ryan C. Gordon 2015-04-06 16:53:01 UTC 
Anyhow, I'm going to remove this from the 2.0.4 todo list. We'll figure it out later, I hope.

--ryan.
Comment 5 Ryan C. Gordon 2020-03-25 00:25:29 UTC 
Consolidating this with Bug #5041.

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