I''ve been working on a Videoscape reader for my project; reading them into custom data structures for rendering via OpenGL. It loads the data OK, no problem. However, when I try to free the memory from the object, the free() call is seemingly ignored. The data structures consist of a vertex struct(three floats), which are combined in a plane struct(number of vertexes, and a 4-slot array for the vertexes), which are then combined in an object struct(number of planes, and a pointer array for the planes(PLANE *faces). The object is allocated easily(obj->faces = malloc(sizeof(PLANE) * (number of planes)), then the vertexes are correctly read in by the routine. However, when I use the dealloc routine(basically, free(obj->faces), nothing happens. The vertex data stays there, and isn''t freed. Do I have to step through the pointer array manually and free it(gcc doesn''t like it if I try a for loop with free(obj->faces))?

I can''t claim any experience with OpenGL, but I think I can help you generally.

What are you expecting when you call "free". i.e., what do you mean when you say "the free() call is seemingly ignored"?

If you''re running the program in release mode, the only thing free will do is remove that block of memory from the "allocated" list, essentially putting it back in the pool that''s available for the next malloc. There shouldn''t be anything happening with the data, nor with the pointer that points to the data. An analogy:

int *pn = new int; // dynamically allocate an int, pn = some address now
*pn = 5; // set it to some value
delete pn;

(forgive me for not translating to C; I''m pulling an all-nighter here at work, and I figure the less I try to think, the better. Suffice to say that new and delete are like malloc and free without any casting needed)

After the last line there, the memory pn used to point to might very well still contain 5, and pn is definitely still set to the same memory location. If another thread is running around, the memory that used to be taken by the dynamically allocated integer can get clobbered, because it''s been freed. But nothing deterministically happens to either the pointer or the pointee after a free/delete; it''s just that the memory record now indicates that the memory is free to be used by other allocations.

If you''re building with a debug library, you might get your memory that used to contain your integer overwritten by some constant pattern (like 0xBF I believe for MSVC).

The only time you''ll usually be able to detect the fact that a free has been ignored is if you''re using a memory management scheme where leaks are reported. This doesn''t sound like it''s the case, from what you described.

Hope I''ve understood your question and don''t seem patronizing--like I said, it''s very late and my bus lines aren''t all synchronized.

No, you''re fine, with what limited amount I told you(I realize that about new and delete, but I wanted to get it right with malloc/free first). I guess I''m misinterpreting a GDB exit code, so I thought it was complaining about the stack getting clobbered because of a memory leak. Thanks for your rationale anyways.

What exactly happens when you don''t delete something you created with new???

quote:

---

Original post by zell

What exactly happens when you don''t delete something you created with new???

---

You get a memory leak. If you do this many times, eventually you''ll suck up all of your memory and crash the program. The OS is supposed to automatically free leaked memory after a program terminates, but I don''t believe NT does (tested it once, and after successive runs of my leaker program, the page file was not ever decreasing). The same might be true of other OSs.

Resource leaks are the bane of any large project, so there are many methods of trying to structure your code so that it can''t ever leak. Just look on the web (or this site) for memory management topics.

Stoffel: Win NT/2000 *does* reclaim memory used by programs when they terminate. It just doesn''t always restore the page file unless it has to for some reason.