| Summary: | Memory freeing bug in SDL_DestroyRenderer/SDL_DestroyTexture | ||
|---|---|---|---|
| Product: | SDL | Reporter: | felix <felix.von.s> |
| Component: | render | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | blocker | ||
| Priority: | P2 | CC: | icculus |
| Version: | HG 2.0 | ||
| Hardware: | x86_64 | ||
| OS: | Windows 7 | ||
Fixed, thanks! https://hg.libsdl.org/SDL/rev/703e501cd0a6 (In reply to felix from comment #0) > Bug introduced in revision 10650:b6ec7005ca15, which has a somewhat ironic > description of "Fixed all known static analysis bugs"... Sorry, that was my mistake; I didn't realize this called SDL_DestroyTexture internally, too. --ryan. The static analysis concern is more properly fixed by https://hg.libsdl.org/SDL/rev/d8a4f8a929b2 ... it thinks we're reusing a variable that we just freed because it doesn't appear to understand that this is var is getting changed elsewhere, so we add an assert to tell it that it's definitely a different value each time through the loop. --ryan. |
Here's a snippet of SDL_DestroyRenderer from hg revision 10746:95c57a177719: SDL_Texture *texture = NULL; SDL_Texture *nexttexture = NULL; /* ... */ for (texture = renderer->textures; texture; texture = nexttexture) { nexttexture = texture->next; SDL_DestroyTexture(texture); } SDL_DestroyTexture removes the texture from the linked list pointed to by the renderer and ends up calling SDL_DestroyTextureInternal, which contains this: if (texture->native) { SDL_DestroyTexture(texture->native); } If it happens that texture->native is an alias of nexttexture two stack frames up, SDL_DestroyRenderer will end up trying to destroy an already freed texture. I've had this very situation happen in dosemu2. Bug introduced in revision 10650:b6ec7005ca15, which has a somewhat ironic description of "Fixed all known static analysis bugs"...