Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

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...