I think using windbg as suggested there is still a useful tactic. The script that looks into Python objects won't work but looking at !DumpHeap results can still be pretty useful. One easy way to improve this is to use pre-compiled subclasses. An example of that is over in this thread: http://www.mail-archive.com/users@lists.ironpython.com/msg10381.html Once you have the DLL produced you can clr.AddReference() it or put it in the IronPython DLLs directory. That will cause the types to not show up as "UnloadedType" and instead will show up w/ a little more descriptive of a name which includes the base type name.
You can also use CLRProfiler which is pretty useful in that it'll show you charts of where the memory is being kept alive. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Thursday, September 16, 2010 8:40 AM To: Discussion of IronPython Subject: [IronPython] Debugging IronPython 2.6 memory issues Hi, I am having a memory leak issue for quite some time with an application that uses Ipy 2.6. I have been looking for tools that can help me see where is the memory allocated. All I found was this blog entry - http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in-ironpython.html Which seems relevant but as I understand it is not working for Ipy 2.6. Are there any tools that are appropriate for IronPython 2.6? Thanks
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
