[SDL] Memory leak in SDL_putenv() - can it be plugged safely?

Doug biteme at bitbasher.net
Mon Jun 11 23:00:27 PDT 2007


I'm using some of the VS2005 CRT debug functions to track potential 
memory leaks in my program.  To ensure that I catch *all* leaks, in my 
testing debug build I've included SDL and all of the other libraries I 
use in my "catch area" for CRT leak detection.

I've nicely wrapped all my SDL functionality into a C++ "surface" class. 
 The class has a global instance counter.  The constructor makes a heap 
snapshot when the instance count is zero (before incrementing).  The 
destructor does a heap dump (leak check) when the instance count is zero 
(after decrementing).  This all works nicely to detect leaks in my 
program.

The snapshot of the heap is made before SDL_Init() in the construction.  
The heap dump is made after SDL_Quit() in the destructor.

Now, I've noticed I get one and only one memory leak in SDL which is 
caused by any call to SDL_putenv().  The memory allocated by 
SDL_putenv() is never freed, even after SDL_Quit().  The SDL source code 
even let me know this is expected, as in SDL_getenv.c I see:

   static char *SDL_envmem = NULL;      /* Ugh, memory leak */

When my program (in debug mode) exits, I want it to have ZERO memory 
leaks.  To work around the SDL leak, I check to see if I have one single 
leak.  If so, I exit cleanly without reporting any memory leaks.

Now here's my question (finally)...

Is there any reason why SDL can't free SDL_envmem on a call to 
SDL_Quit()?  Are there existing apps that would expect the environment 
to be persistent after SDL_Quit() is called?

I can make this change locally for my use of SDL to make my app leak 
free, so for my own use, it's a no-brainer.  I'm just wondering what 
historical reasons exist (if any) that would prevent SDL_envmem from not 
being freed when SDL_Quit is called.

Thanks,
Doug.




More information about the SDL mailing list