Re: [GD-Windows] memory leak?
Brought to you by:
vexxed72
From: Colin F. <cp...@ea...> - 2002-11-07 13:05:51
|
2002 November 7th Thursday For Visual Studio .NET, the <vector> header has: void clear() { _Tidy(); } The destructor has an identical implementation: ~vector() { _Tidy(); } The vector method _Tidy() supposedly frees all storage. Okay, even if this is not the case on your STL implementation, I don't think this is the cause of your "leak", since you apparently allocate and delete objects that CONTAIN vector objects. Regardless of vector's "shrinking" policy, destruction of the vector object itself should free associated storage. I have three wild guesses about what you might be observing: [A] Best guess: You are doing "new" and "delete" on a regular "struct", instead of a "class". This may simply allocate raw bytes with the same size as your structure. This means that the "std::vector<float> array" member is NOT CONSTRUCTED, but is simply given space to exist. Even though C++ compilers may implement "struct" as "class", I don't know if "new" will CONSTRUCT members of a "struct". Anyhow, I'm guessing that the "delete" calls aren't calling the destructor of the "array" object within the "struct" (TestObj). EXPERIMENT: Change the "struct" to "class" (TestObj), and just add "public:". Don't make any other changes. [B] Some kind of DLL page(s) just wasn't (weren't) added to your process until you touched the "new" and "delete" operators (implemented as malloc() and free(), but enhanced with calls to constructor and destructor functions). So, maybe your program won't grow any more than the observed 28KB even when you "new" and "delete" 2000000 of your objects instead of 200. [C] The C run-time library malloc() and free() are "lazy" when it comes to returning memory pages back to the OS -- for efficiency. So, your process appears to remain bigger even after you free all allocated memory. The C run-time library may have tuned rules to decide when to ask for more memory from the OS, and when it seems obvious from the passage of time that pages aren't likely to be used again and can be returned to the OS. I'll bet the CRT is trying to avoid system calls in a big way. I actually have no idea what might be going on, but it would be interesting to change your loop counters to 200000 iterations instead of 200, and see if the process growth is anything other than 28KB. If not, it would be interesting to reduce the loop total to "1" iteration (a single "new" and "delete"). If this is still 28KB, then it appears that [B] explains everything! Also, it would be interesting to wait a couple of minutes, running other miscellaneous applications that might demand lots of memory, and check the process size of your test application. If it shrinks, then [C] is the likely answer. --- Colin cp...@ea... |