Temple of The Roguelike Forums
Development => Programming => Topic started by: Fenrir on April 17, 2011, 02:41:32 AM
-
Is it likely that SDL and OpenGL have memory leaks in them? That doesn't sound right to me. I'm checking my program with Valgrind, and it says that there are 605 bytes "definitely lost", but it's all from malloc() calls in the SDL and OpenGL code. I call SDL_Quit() at the end of the program, and I delete my OpenGL textures, so I don't know what I'm doing wrong. My tile engine doesn't do anything more involved than render some textured quads.
Assuming of course that these are memory leaks, and I'm not just mistaken about what "definitely lost" means.
-
Only thing I can think of is maybe missing a SDL surface, or possible an array of surfaces? Been a long time since I used SDL, so I'm just taking a shot in the dark because I know that was the source of one of my memory leaks.
-
With hobby projects I am only concerned about memory leaks that build over time, otherwise the OS will deal with it upon program exit :)
My professional projects are a different story though, I would never send any code with memory leaks, but in my experience using open source projects they quite often give memory leaks. I believe I still have leaks in my OpenGl/SDL code base, but like I said the OS will deal with it upon exit.
-
It's possible SDL has memory leaks. Especially 1.3 being as it's still a wip, and especially the more obscure corners of SDL. If OpenGL has memory leaks that's either an issue with your drivers or your code. Again more likely if you use deprecated or obscure functions...
Of course it's also likely you're losing track of a surface or something somewhere in your program. If you're using smart pointers like c++0x/boost's shared_ptr which use reference counting, a common problem people miss is if A has a smart reference to B and B has a smart reference to A, then A and B won't automatically be deleted.
Which means if obj A has a surface, and points to obj B, and obj B has a surface and points to obj A...yeah, that's two surfaces as well as the rest of obj A and obj B's data leaked unless you know this is going to happen so have code to deal with it before-hand.
Of course Ockham's Razor says the simplest explanation is the best, and you've made an easy-to-make minor fuck-up is simpler than your driver developers or the SDL developers have made a major fuck-up xD
-
I'm not sure that your application of Ockham's Razor is entirely correct, but I would rather it was my mistake, as I can repair that. I'm not using anything obscure, but this is the first time I've used either library. There was something about "binding a context" that I didn't do because I didn't really understand what that meant yet, and it was rendering stuff without doing it, so I didn't ask questions. That probably has something to do with it. I'll go look at some more documentation. Thanks for the help, guys.