Christopher Ireland said:
Willy said:
No, as I said, it was a bug in the Windows.Forms code.
Ah, Ok. I read your phrase like this: "[to] illustrate the impact of a bug
[in the GC] in the Windows.Forms code [NumericUpDown being a class in
Windows.Forms]". My mistake, sorry.
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.
Yes, I can understand that.
Involuntarily keeping object references alive when done with them is
a latent bug, you can recover from, not a real leak.
That's certainly the way I saw it before entering into this thread
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.
If there was a "real" leak, as it were, what symptoms could I detect using
perfmon's counters (sorry for being so repetitive)?
Well, perfmon is just another tool, you can get a reasonable idea about your
allocation scheme by watching them, however, the real art is to know which
ones to look at and the ones to ignore, and the ones who might be plain
wrong!.
Memory management is a complex issue, really. Basically, all memory
allocations/de-allocations are made by the OS itself ( by THE memory
manager), every process in Windows starts with a "default heap" at process
creation time, all heaps allocated to a process are reclaimed by the OS when
the process terminates, don't expect to find leaks at this level, this is
really a robust piece of code in the kernel.
Program code (running in user space) can allocate (reserve) space from this
process heap or allocate (request) another (private) heap from the OS.
Program code allocates/de-allocates process heap space by means of a WIN32
API call, program code also calls the C runtime to further allocate memory
space from the aforementioned process heaps, the CLR memory allocator does
exactly that, he calls the OS to reserve a number of process heaps, while he
uses the C Runtime to reserve space from these process heaps for the GC
generational heaps (Gen0, 1, 2 and LOH), the GC allocates/de-allocates
object space from these "CG heaps".
So, you see you need to know exactly what you are after, are you looking for
CLR object allocation/de-allocation counters? then you need to watch the
"CLR Memory "counters (like the Gen0 size, if you interested in the
unmanaged memory consumption, you'll have to watch the Memory counters (eg.
Private Memory counters). Note however, that the GC heaps are taken from the
process heaps so their allocated space is also reflected by the heap
counters (Private Memory).
Again all this is something that takes time to grasp, if you can't spend
some time to learn all this, you'll have a hard time when debugging at a
reasonably low level, so if you don't think you need this knowledge, no
problem, spend most of your time by getting your design at the right level
and stay away from low level debugging, or make sure you know someone who
knows it, so you can get some help, instead of wasting precious time.
Willy.