Advertisement

What's automatically dealloc'ed at program termination?

Started by July 28, 2004 05:24 AM
12 comments, last by _DarkWIng_ 20 years, 4 months ago
Hey, What do I have to deallocate myself at program termination and what is automatically deallocated? - Textures? - VBOs? Are there good and free tools for memory monitoring? I'm an absolute noob in that area, so are there also some tutorials on how to use them? I've written some program using quite an ammount of texture and VBO space and I don't allocate all of them when I terminate the program. When I execute it a couple of times, it eventually crashes after a while. So I assume it's the GPU memory that's dying... Lutz
You have to deallocate everything you created. Its not safe to rely on something being "automatically" deallocated. In fact, there might be some mechanism doing this, but, its unsafe. deallocate everything you created.
Advertisement
With OpenGL, anything that you created is "deallocated" when the context is lost (memory leaks can't happen on a video card). However anything that's been allocated with malloc has to be freed before the program returns.
Quote: Original post by Anonymous Poster
However anything that's been allocated with malloc has to be freed before the program returns.

Any decent operating system will reclaim the resources when the program exits, just like, as you said, any decent driver will free the resources allocated in OpenGL.

While you don't explicitly have to, it certainly is a good thing to do it yourself. Memory leaks is not really a problem when the program exits, but rather while it's executing. For example, if you don't free the resources from the old level when loading a new one, your program will consume more and more resources as you load new levels, and at some point your level will fail to load.
Hmmm, what could then be the explanation that my system crashes when I execute my program for the 20th time or so?
Well, there is, of course, a possibility that there's a bug in the driver which doesn't release the resources properly. You could try another driver and see if it's the same problem. Does the problem go away when you use less resources, or at least takes longer before it crashes?
Advertisement
I remember ATi having some problems with memory deallocation with VBO in early implementations, but that's fixed now. But it is a good practice to release everything you allocated. Both in system memory and things under opengl's control. It somethimes even helps you find some hidden bugs you didn't even notice before.
You should never let your fears become the boundaries of your dreams.
Brother Bob, I don't think it's a bug in the driver since it also happened with my old GF2 MX400 (just that the computer crashed completely and I had to cold-reboot all the time). Now with my ATI RadeOn 9800 Pro it still crashes (but a usual windows-reboot is sufficient;-).

If I use less resources / activate texture compression, it does take a longer time before it crashes. So I thought it was a memory leak on the GPU.
Probably this is not an error with deallocating memory... sounds like some random pointer wich points to some "valid" part of memory ten times but points to nirvana on the eleventh time ;-) I had a similar problem some time ago.

Rasfunk
Maybe. That would explain why it sometimes crashes earlier, sometimes a bit later.

But how on earth do I detect such a pointer thing?

This topic is closed to new replies.

Advertisement