|
Leaking memory with IronPython.Compiler.Options.GenerateDynamicMethods
= false isn’t really a big issue: ClrDebuggingEnabled = true already
starts to leak memory (at least that’s what the comment says). Is there any complete documentation about
what actions cause memory leaks? By following this mailing list and looking at
the source code comments I know of some things, but I’m sure that I don’t
know all situations. Maybe it would be a good idea to have a setting
AllowMemoryLeaks which has a default of false. Whenever you go through a code
path that is going to leak memory through code generation you could throw an
exception. This way, you know at least that something you’re doing is
wrong. If you’re OK with the memory leak, then you could set AllowMemoryLeaks
to true. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde The first issue is
probably the same that IL offset 0 does not have any debug information. Calling the delegate
“add” steps into a DynamicMethod which confuses VS. A workaround
for now is to add this statement before creating the PythonEngine. IronPython.Compiler.Options.GenerateDynamicMethods
= false; This disabled the
use of DynamicMethods altogether and will instead use AssemblyBuilder. This is
not generally recommended or supported since you are going to leak memory since
AssemblyBuilder memory cannot be reclaimed. However, VS seems to be better able
to deal with AssemblyBuilder during stepping, and it might be good enough for
you. This is a case where we will would need to teach the tool (VS) to handle
DynamicMethods differently than it currently does. |
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
