memory not released by delete[] operator
RocketRob
the new[] operator. All of these items are subsequently released using the
delete[] operator.
The problem I am having is that the memory allocation for the product
continues to increase as it continues to be used. It does not seem to free
or even re-use the memory that it has gobbled up while running until exiting
the program.
This did NOT happen while the product was compiled under VC++ 6. It does
happen now under VC++ 2005 (incidentally, we're using SP1).
What can I do to force it to flush and/or reuse the memory it has taken?
I have lost the better part of several days on this and am completely out of
ideas. Any assistance would be greatly appreciated.
Thanks,
Rob
Ulrich Eckhardt
> I have an unmanaged C++ project that allocates most arrays at run time
> using the new[] operator. All of these items are subsequently released
> using the delete[] operator.
This is error-prone and hard to code in a reliable, exception-safe way. You
should be using std::vector instead.
> The problem I am having is that the memory allocation for the product
> continues to increase as it continues to be used. It does not seem to
> free or even re-use the memory that it has gobbled up while running until
> exiting the program.
Make above switch or create a minimal example, otherwise it's hopeless to
diagnose the problem.
> This did NOT happen while the product was compiled under VC++ 6. It does
> happen now under VC++ 2005 (incidentally, we're using SP1).
Two choices:
1. The VC8 compiler is buggy.
2. Your code is buggy, in that it relied on things that are given under VC6
but now don't work anymore.
Considering that the operation of new/delete is very basic, I guess it's the
second, sorry.
> What can I do to force it to flush and/or reuse the memory it has taken?
You shouldn't need to.
> I have lost the better part of several days on this and am completely out
> of ideas. Any assistance would be greatly appreciated.
There are debug allocators like the '#define new DEBUG_NEW' that is used by
default in some projects. There are other "memory debuggers" out there,
too.
Uli
Carl Daniel [VC++ MVP]
What are the sizes of the objects being allocated? Are they always the
same? Do they grow over time? You may be encountering a case of heap
fragmentation where there simply aren't large enough free space blocks in
the heap, so a new allocation has to be taken from the OS.
You could try enabling the low fragmentation heap for your process (google
it - you'll find dozens of references), you might also experiment with the
_set_sbh_threshold function. The default value of the small block threshold
was changed between VC6 and VC8 (in VC7 or 7.1, I don't recall which), and
that can have a deleterious effect of some program (and a beneficial effect
on others). IIRC, the default under VC6 was about 1024 bytes.
If neither of those help, post back - there are lots more tools that can be
brought to bear.
-cd
RocketRob
So, I tried the call to _set_sbh_threshold and it asserts, so that isn't the
way to go, it seems...
One thing I've noticed which is very curious: If I let the app run for a
bit and let it grab memory doing its things.... if I then MINIMIZE it... all
of the memory resources are freed at that point. Immediately.
So, now what I need to figure out is what is happening on the MINIMIZE event
that could free all of this memory.
Any suggestions on that one?
Thanks.
Alex Blekhman
> One thing I've noticed which is very curious: If I let
> the app run for a
> bit and let it grab memory doing its things.... if I then
> MINIMIZE it... all
> of the memory resources are freed at that point.
> Immediately.
>
> So, now what I need to figure out is what is happening on
> the MINIMIZE event
> that could free all of this memory.
Oh, it seems you check memory usage with Task Manager, do
you? Taks Manager is not the right tool for this job. It
doesn't show the memory you allocate. It shows current
memory working set of a process. Process working set is a
set of memory pages your process ever touched but system
didn't reclaim it back yet. System keeps these pages in
process working set in case process will require them soon,
so allocation will spare a page fault.
When application's main window is minimized, then system
assumes that user won't use this process for some time, so
its working set is trimmed to absolute mimium required by
the process.
Read here more about working set:
"Process Working Set"
http://msdn2.microsoft.com/en-us/library/ms684891.aspx
If you need to measure actually allocated memory, then use
Performance Management Console (Control Panel ->
Administrative Tools -> Performance). Select "Process"
performance object, then choose a process you want to
monitor. From counters list select "Private bytes" counter.
Alex
RocketRob
So, the real issue I am having is that when running some large processes
repeatedly, it eventually fails with an 'out of memory' error. But, if I
minimize the app in between runs of this memory intensive process, this does
not happen.
Alex Blekhman
> So, the real issue I am having is that when running some
> large processes
> repeatedly, it eventually fails with an 'out of memory'
> error. But, if I
> minimize the app in between runs of this memory intensive
> process, this does
> not happen.
It sounds strange since working set of a process is
sacrificed first when memory is required for other
processes. You can observe it by launching Excel or Word,
for example, with rather big document. Then, while Word
starts, look in Taks Manager how working sets of other
processes decrease. If you have memory leaks, then working
set mechanics is not the factor that will influence it. If
your application has complex paint logic, then minimize
could disturb it indirectly, but not likely. Other than
that, you should use memory leak detection tool to be 100%
sure.
Alex
RocketRob
GetColumnInfo() was chewing up resources because the call to IMalloc->Free()
was failing. Changing it to CoTaskMemFree() for each of the OLEDB-allocated
buffers fixed everything. Memory utilization is now down from 1.5 GB to 17
MB... right where it should be.
Thanks,
Rob