Re: Tracking a memory leak.

"Frank Rizzo" <none@xxxxxxxx> wrote in message news:OPTBaFDlHHA.3280@xxxxxxxxxxxxxxxxxxxxxxx
I have an object tree that is pretty gigantic and it holds about 100mb of data. When I set the top object to null, I expect that the .NET framework will clean up the memory at some point. However, I am looking at the Task Manager and I don't see the MemUsage column decreasing even after an hour or two. I know that TaskManager may not be the best place to see what is the true way to gauge memory usage and/or presense of memory leaks. So I am looking for a pointer on what I should use to see whether setting an object to null really will at some point free up memory.

Regards


You should take a look at the "CLR Memory performance" counters, notably the Gen0, 1, 2 and Large Object heap counters are of interest.
What is shown in Taskman is the size of your process Working Set or the Private Bytes (depending the counter you are looking at), the GC allocates and de-allocates object space from a Private Heap holding the above generational heaps, this Private Heap,w which is part of the Private Bytes and the Working Set, grows, by requesting new segments from the OS, whenever the Generational heap 0 is full and the GC needs more space to allocate objects from.
However, this heap will not necessarily decrease when objects are getting GC'd, all the GC does is free the object space and compact the generational heaps (0, or 0 and 1, or 0, 1 and 2).
The CLR "Memory Allocator" de-commits (after compactation) the pages that were previously occupied by object data, and returns the Segment to the OS when *all pages* from that segment (but not the default segments) are decommited.
Note that pinned objects can spoil the party, as these cannot move to another segment and as such prevents the Segment to become de-committed completely. Another thing that you need to watch for is the LOH, as this heap is never compacted, keeping objects alive in one of the possible extra segment for this LOH, will prevent the segment to return to the OS.

Willy.

.

Relevant Pages

  • Memory problems - WinDbg and SOS: Who recognizes this pattern?
    ... Last night I managed to get a memory dump using ADPlus and I analyzed it ... ephemeral segment allocation context: none ... Large object heap starts at 0x0a0d0030 ...
    (microsoft.public.dotnet.framework.performance)
  • heapcreate/heapfree and reserved segments
    ... uncommitted memory available within the address space of the process. ... When we analyze heap utilisation in process dumps from the site we ... an initial 256KB segment is reserved. ... allocations since the amount of VM address space overhead that will be ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Memory management terminology
    ... We've ruled out a memory ... and let's assume that heap fragmentation is not the problem. ... While not directly a memory leak, ... it is indeed "private bytes" that we're measuring. ...
    (microsoft.public.vc.language)
  • Re: ptrs validity
    ... I have a pointer that points to an unknown heap memory block, ... hardware checked segment for each allocation. ...
    (comp.lang.c)
  • Re: where do the automatic variables go ?
    ... which will be placed in the .text segment: ... from the heap. ... responsibility for mapping this to physical memory. ... As you program starts generating stack frames and automatic variables, ...
    (comp.lang.c)