> On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer <cgen...@gmail.com> wrote:
> > On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland <di...@microsoft.com> wrote:
> > I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
> > constant at 1.. I'm not very familiar with windbg but I can certainly
> > learn more about it.. What should I be looking for?
>
> You could try running it under CLRProfiler:
>
> http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-
> 8926-862b40aa0cd0&DisplayLang=en
>
> http://msdn.microsoft.com/en-us/library/ms979205.aspx
>
> With it you can see which objects stick around after a GC, what's
> holding those objects, and where they're allocated. I'm not too
> familiar with its use yet, but I plan on doing that tomorrow.
Yeah CLRProfiler is a little more friendly :) I like windbg because it gives
reasonable way of tracking who's keeping what alive and I find it a little more
reliable than CLRProfiler. What I usually do is attach to the process after
letting it leak for a while and then:
.loadby sos mscorwks
Or
.loadbys sos clr
For CLR v2 and CLR v4 respectively. Then you can do:
!DumpHeap -stat
Run for a while, repeat that, and look at what types of objects are growing.
They should be at the end of the list because after running for a while they're
growing the most. Then you can do:
!DumpHeap -mt <method_table>
Where <method_table> is the address for the type that !DumpHeap -stat gave you.
Then you can start picking objects at random and do:
!GCRoot <object_addr>
And you see who's keeping it alive.
If the leaks big the places to look at pretty obvious. If it's leaking Python
objects defined in classes though you'll see those as "Unloaded Type".
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
