| Summary: | Memory leak in minimal example program caused by SDL_ClearError | ||
|---|---|---|---|
| Product: | SDL | Reporter: | sdlbugs |
| Component: | thread | Assignee: | Ryan C. Gordon <icculus> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | alexlsh, diegoacevedo91, icculus, jack9267, sdlbugs |
| Version: | 2.0.10 | Keywords: | target-2.0.16 |
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugzilla.libsdl.org/show_bug.cgi?id=3317 https://bugzilla.libsdl.org/show_bug.cgi?id=2771 https://bugzilla.libsdl.org/show_bug.cgi?id=4055 https://bugzilla.libsdl.org/show_bug.cgi?id=4749 |
||
| Attachments: | Diff for fixing leak in SDL2-2.0.12 | ||
|
Description
sdlbugs
2020-03-17 08:55:39 UTC
So the concern is that we can't clean up the main thread's TLS data because it has to live outside of SDL_Init/SDL_Quit, as you can have an SDL error outside of a successful init; if nothing else, SDL_Init can fail and this code pattern is considered legal:
if (SDL_Init(SDL_INIT_VIDEO) == -1) {
// SDL_GetError() uses TLS internally to store an error per-thread.
printf("SDL_Init failed! reason: %s\n", SDL_GetError());
}
I suppose that SDL_Quit() could clear the main thread's TLS, if:
- we know SDL_Quit is being called on the main thread, because other threads will clear their TLS on termination. Even if we don't have a system API to decide if we're on the main thread, we _could_ hook into SDL_CreateThread's startup code to mark a thread as not-the-main-one. This will cause problems if someone spins a thread through a system API directly instead of SDL and then calls SDL_Quit, but that's an unlikely case that we can say they shouldn't do.
- If the app does something that generates an SDL error after Quit, or even calls SDL_GetError(), it's going to regenerate the TLS data, but that's now an application bug instead of an SDL bug.
I don't know the full ramifications of doing this, as I'm not super familiar with the TLS code. I'm just talking out loud, but this bug report does pop up with some frequency and I'd like to prevent that as much as the memory leak. :)
--ryan.
Could have an SDL_Cleanup() function that clears it? (In reply to Ryan C. Gordon from comment #1) > So the concern is that we can't clean up the main thread's TLS data because > it has to live outside of SDL_Init/SDL_Quit, as you can have an SDL error > outside of a successful init; if nothing else, SDL_Init can fail and this > code pattern is considered legal: > > if (SDL_Init(SDL_INIT_VIDEO) == -1) { > // SDL_GetError() uses TLS internally to store an error per-thread. > printf("SDL_Init failed! reason: %s\n", SDL_GetError()); > } > > > I suppose that SDL_Quit() could clear the main thread's TLS, if: > > - we know SDL_Quit is being called on the main thread, because other threads > will clear their TLS on termination. Even if we don't have a system API to > decide if we're on the main thread, we _could_ hook into SDL_CreateThread's > startup code to mark a thread as not-the-main-one. This will cause problems > if someone spins a thread through a system API directly instead of SDL and > then calls SDL_Quit, but that's an unlikely case that we can say they > shouldn't do. > > - If the app does something that generates an SDL error after Quit, or even > calls SDL_GetError(), it's going to regenerate the TLS data, but that's now > an application bug instead of an SDL bug. > > I don't know the full ramifications of doing this, as I'm not super familiar > with the TLS code. I'm just talking out loud, but this bug report does pop > up with some frequency and I'd like to prevent that as much as the memory > leak. :) > > --ryan. Yes, this sounds like a good approach. *** Bug 3317 has been marked as a duplicate of this bug. *** *** Bug 4055 has been marked as a duplicate of this bug. *** |