Valgrind: memleak my fault or bug? |
brada
|
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.
|
|||||||||||
|
Valgrind: memleak my fault or bug? |
Ryan C. Gordon
Guest
|
On 08/12/2015 12:20 PM, brada wrote:
Even better to check: did you definitely SDL_DestroyTexture(renderTexture) before the end of the program? --ryan. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Murenius
|
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? |
|||||||||||
|