I'm trying to locate a memory leak..

I've a test app which creates an instance of a big class, null's the
reference, then calls GC.Collect() a few times in an attempt to clean up
any memory. Thus, in thory, I don't think my instance should exist
anymore.

I use SOS (within the IDE):

!name2ee gives me the method table for my class
!dumpheap -mt xxx -> lists the object instance that I think should have
be GC'd
then !gcroot <instance address> to look to see what's still holding it.

The only root displayed starts:

DOMAIN(0014C278):HANDLE(WeakSh):9f127c:Root:014153 8c
(MyNamespace.SomeOtherClass)->

which I thought meant that this was a weak handle that won't be keeping
the instance alive.

Am I misunderstanding how gcroot works?

If I then "!gcroot 0141538c" I get a pinned object[] root (which is
probably the overall cause of the problem, therefore), but why doesn't
this one show up when I gcroot the original class instance?

Get the whole story here (especially !gchandles as you do have a handle
here)

http://blogs.msdn.com/mvstanton/arch...11/479861.aspx

"AJ" <noone (AT) nowhere (DOT) com> ha scritto nel messaggio
news:MPG.20fc3f80a06d03c39896ad (AT) news (DOT) zen.co.uk...

If you're in the IDE running SOS, you're running in Debug mode. Strange
things happen in debug mode with regard to object lifetimes and GC. Given
that you're nulling out the reference, I find it hard to accept, but it
*could* be part of the problem. I'm reaching though, I admit.

You may want to try compiling in release mode, running your app, generate a
dump, and then load that into WinDbg / SOS and poke around that way.

As a quick aside, there is a better tool for debugging this than !gcroot.

I've been really happy with sosex.dll, as it's made doing this stuff in
WinDbg much easier:
http://www.stevestechspot.com/SOSEXA...nagedCode.aspx

[John Robbins talking about it]
http://www.wintellect.com/cs/blogs/j...s-my-hero.aspx

--
Chris Mullins

"AJ" <noone (AT) nowhere (DOT) com> wrote