Re: GC.Collect can be trusted?

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Christopher Ireland" <cireland@xxxxxxxxx> wrote in message news:3F2E0FCE-6917-4D3F-AB6A-CFC5FA43CFFD@xxxxxxxxxxxxxxxx
Willy Denoyette [MVP] wrote:
Note also, that this article was written years ago, and is based on
the first version of the framework and never updated since then.
These are the kind of "look how great our product is, it can even
find bugs in MSFT's products" articles, but they did not find
anything, this bug was known at the time they ran the profiler, all
they did was illustrate the impact of a bug in the Windows.Forms code
on the allocation pattern.

So it was a bug in the GC then?


No, as I said, it was a bug in the Windows.Forms code.

You won't be able to find these kind of "bugs" using just a profiler,
you need a debugger, a great deal of understanding how the GC and the
CLR works, a lot of experience in debugging complex systems plus
quite some luck to finds small leaks like these. Granted, a profiler
is something you need in your toolbox, it's a great tool to
illustrate performance behaviors and uncover possible bottlenecks, it
can help you better understand your object allocation patterns, where
you allocate too many or to large objects, so you can adapt your
algorithms and allocation needs, but you won't ever be able to detect
small managed memory leaks by using a profiler alone.

I can tell you now that I have very little time to spend tracking down bugs in the GC. What I'm after is being able to track down memory leaks that I unwittingly create in the code I write. The question is: are the bugs I introduce into my code through the allocation of too many or too large objects really "memory leaks" (please, this is not a trick question, I'm really trying to figure out what's going on here :-) ?


Again, you don't have to, nor can you even track down bugs in the CLR's code like the GC, not because you don't have the time to do so, but because you are missing what I call essential when debugging a complex system like the CLR, it's the source code and a deep understanding of the internals of the CLR and the underlying platform. This is something you have to leave to the CLR team at MS, really.
Allocating too many and/or too large objects ( too complex and/or too large object hierachy) is basically a design mistake , which can possibly lead to runtime errors and/or bad performing applications (that is, it becomes a bug), but they are no leaks. Note, that while such applications can fail on some systems, they can perfectly run on system that have a lot of memory/cpu resources available. Involuntarily keeping object references alive when done with them is a latent bug, you can recover from, not a real leak.
A "real" leak is something you can't recover from, for example, an object that stays allocated in the heap, despite you no longer have live references to it in your code, there is little you can do about this and when it happens it will go undetected, unless it happens regularly in a long running process.

Willy.

.

Relevant Pages

  • Re: GC.Collect can be trusted?
    ... anything, this bug was known at the time they ran the profiler, all ... on the allocation pattern. ... I can tell you now that I have very little time to spend tracking down bugs in the GC. ... What I'm after is being able to track down memory leaks that I unwittingly create in the code I write. ...
    (microsoft.public.dotnet.languages.csharp)
  • A lowly newbie humbly asks for a clue
    ... A memory block has been leaked. ... The allocation number is: 1301 ... Current memory dump of 256 bytes starting at pointer address 2444AD8: ... The small block leaks are (excluding ...
    (borland.public.delphi.language.basm)
  • Re: command line tool for finding mem leaks?
    ... man leaks ... the top few stack frames of the allocation of each leak. ... if(foo!= fum){ ... delete foo; ...
    (comp.sys.mac.programmer.tools)
  • Re: CRT block leaks
    ... I want to get rid of leaks in the ... my application does not break at the allocation number. ... Validator and set the DLLs to Hook feature to identify your DLL only, ...
    (microsoft.public.vc.debugger)
  • Re: FastMM <-> MemCheck
    ... > the leaks in details just like MemCheck does. ... project is new or a decade old, such bugs should be smashed rigorously. ... could be a good idea to give the FastMM reporting feature a new try. ...
    (borland.public.delphi.non-technical)