I recently started using the CLR profiler to track down a memory leak. After playing with it for a while, I am starting to get the hang of it. However, the different screens seems to give me different resutls.
For example, I am running profiling an app that opens up a dialog window with a main menu. What seems to be happening is that the Dialog form remains after it is close and even after I call dispose.
- Allocation by address shows "n" instance of the form.
- Show Heap shows only a different number of instances.
- The timeline shows different values as well.
In the case of timeline, the manual did say that the timeline does not always capture all objects. However, is Allocation by address accurate Dose show heap always show the correct number
CLR Profiler results are conflicting
ericjs1
Make sure you're not profiling with a debug build.
Dispose doesn't cause a garbage collect. It is intended for releasing unmanaged resources in a deterministic way (like a wrapped Win32 handle). If the object is in fact unreachable it is a candidate for GC, but there's nothing about calling Dispose or Close that makes the object actually unreachable.
Mike Suarez
I am aware that dispose doesn't really garbage collect, but the form is staying around forever in the heap (or at least for a very long time).
However, the object is staying in the heap. Here's one thing I can't figure out. If the object is just sitting on the heap, how can I tell if it is a candidate for garbage collection I assume that it would be object not connected to root, all of the objects in the heap graphs seems to be connected to root.
mdenomy
I assume that the Show heap is the accurate figure because it is a dump of the heap at the time the Show heap is pressed.
I also assume that all objects on the heap graph are connected to root. I am thinking that there are plenty of dead objects on the heap. It would make the most sense to display only objects that are reachable by root. Objects not reachable by root are assumed not to be displayed.
Big5824
I'm not familiar enough with the profiler, but I thought there was a way to find roots in those kinds of cases.
It's my general understanding that events (delegates etc) can sometimes be responsible for keeping things like a form alive because (and I don't recall the details) event handlers can be methods in other objects that are still alive (and perhaps static) and can keep the form or control reachable. A wild *ss speculation of the kind of thing I've heard about: a control eventhandler coded in a static class might keep that control reachable. The static stays around, and its delegate is hooked to the control. Caveat again: this is just the kind of thing I've heard mentioned, but it might help you figure out where to look.