I know it's good practice but I rarely bother to delete my heap memory at the end of a program (modern OSes deal with it, I've heard Apple now even prefers programs to exit 'un-gracefully' for efficiency reasons).
I was wondering, is this also OK for graphics memory - i.e. OpenGL buffer objects? Can I trust the OS to deal with this too, or will repeat executions of my program gradually fill up a card's memory? How about unbinding attribute indices? Shader programs and their component shaders?
Also, I'm using 'the default' Vertex Array Object in GL3.3, because I have no need to generate my own (I won't use more than one). Do I need to clear it with glDeleteVertexArrays()?
I'm inclined to believe all this vanishes at the end of execution as with non-graphical programs. Is this correct?
Cleaning up after you're done with OpenGL
Yes, the OS will clean up for you once the process exits. No point in doing what the OS can do much more efficiently anyway.
That said, I recall older Ati drivers crashing when you exited with a bound shader (or was it a FBO?) but this was fixed years ago.
That said, I recall older Ati drivers crashing when you exited with a bound shader (or was it a FBO?) but this was fixed years ago.
Quote:Original post by Fiddler
Yes, the OS will clean up for you once the process exits. No point in doing what the OS can do much more efficiently anyway.
While they can do it, that doesn't mean it always will do it.
They are not guaranteed to do it, and standards to not require it. It is not a safe thing to rely on.
On the PC, most drivers and systems will release memory when your app closes, but they aren't perfect. Sometimes your resources will leak until the system is reset.
If you are writing portable and safe system-friendly code, you need to release all your resources before exiting.
Yes, a few individual systems or sub-systems might be able to clean up faster if they know the app is closing, but it is generally unwise to rely on unspecified non-standardized behavior.
Author
Good points, if I ever distribute what I'm writing I'll write a function to do it. Is there a dedicated page on cleaning up GL3.1+ that lists everything that needs doing?
Based on this, I've got:
disabling shader attributes via their indices
Detaching shaders from shader program
Deleting shaders and shader program
Deleting buffer objects
Deleting vertex array objects
deallocating any heap memory
I'm still wondering whether I need to delete the default VAO in any way (and if so, how to do this). Furthermore, I note the tut writer doesn't unbind the active VBO before deleting them. I assume you also don't need to unbind element index buffers before deleting?
Thanks for your help.
Based on this, I've got:
disabling shader attributes via their indices
Detaching shaders from shader program
Deleting shaders and shader program
Deleting buffer objects
Deleting vertex array objects
deallocating any heap memory
I'm still wondering whether I need to delete the default VAO in any way (and if so, how to do this). Furthermore, I note the tut writer doesn't unbind the active VBO before deleting them. I assume you also don't need to unbind element index buffers before deleting?
Thanks for your help.
Quote:Original post by frobQuote:Original post by Fiddler
Yes, the OS will clean up for you once the process exits. No point in doing what the OS can do much more efficiently anyway.
While they can do it, that doesn't mean it always will do it.
They are not guaranteed to do it, and standards to not require it. It is not a safe thing to rely on.
On the PC, most drivers and systems will release memory when your app closes, but they aren't perfect. Sometimes your resources will leak until the system is reset.
If you are writing portable and safe system-friendly code, you need to release all your resources before exiting.
Yes, a few individual systems or sub-systems might be able to clean up faster if they know the app is closing, but it is generally unwise to rely on unspecified non-standardized behavior.
To clarify my suggestion: wgl/glXDeleteContext and agl/egl/CGL/DestroyContext release associated OpenGL resources automatically (VBOs, shaders, etc). No point in releasing resources yourself when you can just destroy the context.
You should probably kill file handles, network connections and temporary files explicitly but there really isn't any point in releasing heap memory before killing the process. See also: What operating systems won't free memory on program exit?.
Quote:Original post by FiddlerThat doesn't fully address it.
You should probably kill file handles, network connections and temporary files explicitly but there really isn't any point in releasing heap memory before killing the process. See also: What operating systems won't free memory on program exit?.
There have been many times in debugging where I have discovered a file was locked by the OS. (There are various tools to reveal who has a file locked, such as "WhoLockMe".) There are times when a file remains locked long after the locking program has been forcibly killed by the debugger.
Over the years I have seen many drivers where (either by bug or poor design) if you didn't properly release them, they never reclaim the memory.
And there are the bugs; sometimes drivers try to use data from the improperly terminated program, either causing instability or even a cascading driver crash that the OS must handle.
While you are mostly fine with discarding your heap memory (as both people pointed out), there are many other resources out there.
Also, assuming your program will continue to grow (and if it's something like a game or whatever), you won't necessarily want to keep resources around that you aren't using. If you don't bother to clean anything up, you'll just end up gobbling more and more graphics memory every time you load a level / whatever, until you run out.
Sure, this might not be likely for what you're doing, and might not happen unless someone plays for hours, but why leave the door open for this to happen?
Fiddler points out that OS's do free heap memory, but seems to be ignoring the answer that then goes on to point out that one really, really should do this oneself.
Sure, this might not be likely for what you're doing, and might not happen unless someone plays for hours, but why leave the door open for this to happen?
Fiddler points out that OS's do free heap memory, but seems to be ignoring the answer that then goes on to point out that one really, really should do this oneself.
Quote:Original post by frobQuote:Original post by FiddlerThat doesn't fully address it.
You should probably kill file handles, network connections and temporary files explicitly but there really isn't any point in releasing heap memory before killing the process. See also: What operating systems won't free memory on program exit?.
There have been many times in debugging where I have discovered a file was locked by the OS. (There are various tools to reveal who has a file locked, such as "WhoLockMe".) There are times when a file remains locked long after the locking program has been forcibly killed by the debugger.
Which is why I said you should kill file handles explicitly.
Quote:Over the years I have seen many drivers where (either by bug or poor design) if you didn't properly release them, they never reclaim the memory.
Do those drivers leak memory even when you call wglDeleteContext? I guess such drivers might exist, but Nvidia, Ati and Intel drivers all seem to release memory properly.
Quote:Original post by sprite_hound
Also, assuming your program will continue to grow (and if it's something like a game or whatever), you won't necessarily want to keep resources around that you aren't using. If you don't bother to clean anything up, you'll just end up gobbling more and more graphics memory every time you load a level / whatever, until you run out.
Very true. However, we are specifically talking about process exit, not about memory management in general.
Quote:Fiddler points out that OS's do free heap memory, but seems to be ignoring the answer that then goes on to point out that one really, really should do this oneself.
I'm not sure I can understand this sentence.
Quote:Original post by frobDebuggers are black magic. This type of problems happens a lot to me in MVS when dealing with Code Analyst. Sometimes debugged processes will also end up zombified with no way to kill them.
There have been many times in debugging where I have discovered a file was locked by the OS. (There are various tools to reveal who has a file locked, such as "WhoLockMe".) There are times when a file remains locked long after the locking program has been forcibly killed by the debugger.
I can't recall encountering such problem with regular applications calling exit() or similar on themselves. If anything, sound drivers and third-party video codecs are a mess.
Quote:Over the years I have seen many drivers where (either by bug or poor design) if you didn't properly release them, they never reclaim the memory.
While true, a bug is a bug. The fact it works with "proper" shutdown, whatever that might be, is just as much luck as the fact it might now work in absence or proper cleanup.
And I really cannot recall any persistent leaks since Windows 3. In video drivers... Maybe in early XP days. Not saying many drivers aren't crappy, but for most part Windows doesn't leak anymore.
Or better yet - the proper solution requires proof that application has really cleaned up everything. During normal operation, failure to clean up properly will be obvious. During shutdown, just call exit(), try to do full cleanup if someone complains.
But I really don't think this is big a deal. If anything, statistically, exit() will solve more problems than it will cause (such as runaway threads, deadlocks, especially in third-party software). There is nothing worse than application taking forever to shut down or hanging doing so. At least with straight termination it's almost guaranteed to die that very moment.
But the practical answer in this case is - under mainstream OSes it is valid to assume OS will cleanup everything until confronted with concrete opposing evidence. In which case it's still possible to revert to manual cleanup (since that is needed for normal operation).
This still raises big concerns about how you are handling your resources. Are you coding only in raw C? If you are coding in C++, you should have well-designed objects that take care of setup and cleanup automatically. It should be habit that you have solid mechanisms for handling everything. Lazily letting the system clean up the mess means you will run into memory leaks later and have no idea where they are coming from.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
