| Summary: | Memory leaks in SDL init/deinit | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Alex <alexlsh> |
| Component: | thread | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | philipp.wiesemann |
| Version: | HG 2.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.libsdl.org/show_bug.cgi?id=5041 | ||
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. 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! (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. Anyhow, I'm going to remove this from the 2.0.4 todo list. We'll figure it out later, I hope. --ryan. |
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.