Valgrind: memleak my fault or bug?

Hi guys,

after my basic game structure is set up I now would like to clean everything up a bit and optimize it. For this I grabbed a valgrind tutorial and used it on my project. I realize that some reports are not a problem since the memory is still reachable and others are known bugs in sdl or sdl’s dependencies.

So I now want to add suppressions for all those things I can identify as “not a real problem”. However there are some things where I am unsure how to decide if it is a mistake on my side or without my sphere of influence. How can I decide this?

For example, I get the following valgrind output:

Code:

==7575== 8 bytes in 1 blocks are possibly lost in loss record 62 of 1,543
==7575== at 0x4C2C100: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7575== by 0xEA5C09F: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE9987FD: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE90AC4B: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE99A89F: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE99A990: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE9AE48C: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0xE9AF7CF: ??? (in /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so)
==7575== by 0x4E949CD: GL_CreateTexture (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7575== by 0x4E8D49A: SDL_CreateTexture_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7575== by 0x4E8D3D6: SDL_CreateTexture_REAL (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7575== by 0x40D285: initTextures(SDL_Renderer*) (SomeFile.cpp:124)

The code around line 124 is:

Code:

123: SDL_Texture* renderTexture = NULL;
124: renderTexture = SDL_CreateTexture(pRenderer, SDL_PIXELFORMAT_RGBA8888, SDL_TEXTUREACCESS_STATIC, defaultConfiguration.getScreenWidth(), defaultConfiguration.getScreenHeight());

pRenderer is initialized earlier and works just fine. getScreenWidth()/getScreenWidth() just return a constant from a global configuration object.

Do I do something wrong? From the summary in valgrind I’d say that ~1MiB is not that much memory on the heap.

Code:

==7575== HEAP SUMMARY:
==7575== in use at exit: 1,224,932 bytes in 4,783 blocks
==7575== total heap usage: 214,028 allocs, 209,245 frees, 52,837,960 bytes allocated

I dont know if its an actual leak or not, but its hard to blame SDL for it. The trace flags operator new(unsigned long) which is called via vmwgfx_dri.so. that doesnt mean SDL didnt do something wrong I guess; you would have to look into the implementation of GL_CreateTexture for your system and see if its doing something wrong.

Even better to check: did you definitely
SDL_DestroyTexture(renderTexture) before the end of the program?

–ryan.On 08/12/2015 12:20 PM, brada wrote:

I dont know if its an actual leak or not, but its hard to blame SDL for
it. The trace flags operator new(unsigned long) which is called via
vmwgfx_dri.so. that doesnt mean SDL didnt do something wrong I guess;
you would have to look into the implementation of GL_CreateTexture for
your system and see if its doing something wrong.

Thanks for your answers guys, sorry for the late reply - I was away for a few days.

Yes, I definitely destroy all the textures I create, they are wrapped in my own texture class and get destroyed in the destructor as soon as the object goes out of scope.

I just did some more tests and the amount of memory is invariant to the amount of time the application is running. I guess this is indeed some overhead reserved by functions that SDL2 uses. So I guess the best way to deal with this is to suppress those messages at this point in time and only watch for new leaks appearing as I progress in coding my game. Does that sound reasonable?