Why Does Valgrind Say Basic Sdl Program Is Leaking Memory

Why does valgrind say basic SDL program is leaking memory?

Even for basic OpenGL "hello world" program without the full SDL, Valgrind gives me similar warnings deep inside the OpenGL libraries. It's peculiar, but I've assumed

  • The library implementors know what they're doing (probably preallocating some small static buffers they never bother to free),
  • Even if they don't, it's a one-time leak that'll be reclaimed by the OS when the program terminates,

and haven't lost much sleep over it.

Big memory leak in SDL_Init

Yes, there are some leaks in SDL, but it can come from different places and some of them aren't really SDL's fault.

For instance, my video card driver (nvidia) leaks a good 10Mb of memory. X11 is also known for some big leaks. I wouldn't worry that much, there are some things you can't control.

In your specific case, I would run valgrind with the flags --leak-check=full --track-origins=yes --show-reachable=yes, see if the leak is really coming from SDL and post a bug about it in http://bugzilla.libsdl.org if it isn't already reported.

SDL library memory leak

Unfortunately, it's not uncommon for libraries to have memory leaks. As long as it's not the ever-growing kind, it's ugly but no big deal. The OS will free the memory upon application exit. (At least operating systems such as Windows and Linux.)

Memory leak on object destruction

It turns out this leak belongs to layer under SDL, in the X11 library. This bug is very old and known by SDL devs. See this bugzilla thread: https://bugzilla.libsdl.org/show_bug.cgi?id=2086

I close the question now.

Memory leak with SDL2

The failure to free isn't in your code. Digging further with valgrind --leak-check=full, you find the call from your program that generates the allocation is:

==5815==    by 0x400C81: main (ttf-valgrind.c:24)

Which corresponds to:

    SDL_Init(SDL_INIT_VIDEO);

There is nothing related to libSDL2_ttf implicated in the failure to free. The problem arises in libSDL2 and its interaction with libX11. Nothing you can do. You properly clean up:

    TTF_CloseFont(font);

SDL_DestroyRenderer(ren);
SDL_DestroyWindow(win);

TTF_Quit();
SDL_Quit();

While it's not great practice on libSDL2's part, there technically isn't anything wrong with allowing the release of resources to be handled on return from main() and program exit. This appears to be one of those cases.

There are a number of libraries that do this, Gtk included. So you have to take a failure to free when using and third-party library with a grain of salt. Go ahead and chase it down, and satisfy yourself that what is happening is the library is relying on program exit to handle the free. You've done all that you can at that point, unless you want to write and submit a patch to SDL2 that handles it in one of the xxx_Quit() functions.

Is there an acceptable limit for memory leaks?

Be careful that Valgrind isn't picking up false positives in its measurements.

Many naive implementations of memory analyzers flag lost memory as a leak when it isn't really.

Maybe have a read of some of the papers in the external links section of the Wikipedia article on Purify. I know that the documentation that comes with Purify describes several scenarios where you get false positives when trying to detect memory leaks and then goes on to describe the techniques Purify uses to get around the issues.

BTW I'm not affiliated with IBM in any way. I've just used Purify extensively and will vouch for its effectiveness.

Edit: Here's an excellent introductory article covering memory monitoring. It's Purify specific but the discussion on types of memory errors is very interesting.

HTH.

cheers,

Rob



Related Topics



Leave a reply



Submit