[IronPython] Is this memory leak ?

Szymon Kobalczyk s.kobalczyk at softwaremind.pl
Fri Nov 4 23:29:39 CET 2005

But do you have any workaround or maybe some recommendations how to 
handle this. You say that eval doesn't use LCG, so is there any other 
way to use IP that would use it? Or maybe there is a way to compile the 
script snipets only once and reuse them as most of the time they stay 

Any help would be mostly appreciated as now we highly depend on this code.


Martin Maly wrote:

>Unfortunately, this is a known issue that we have on our to-do list.
>The code generated by eval is not generated using lightweight codegen and as such it is not garbage collected. As the result, you see the memory effects you are describing.
>We will definitely fix this by our 1.0 release, most likely even before Beta and I'll try to find some time to look at this even before then depending on my time.
>-----Original Message-----
>From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Szymon Kobalczyk
>Sent: Friday, November 04, 2005 10:13 AM
>To: users at lists.ironpython.com
>Subject: [IronPython] Is this memory leak ?
>We just noticed a serious memory leak in our server application. It happens after we execute some code that uses extensively dynamic scripting with IronPython. After one run the allocation grows from 70MB to more then 500MB.
>I've investigated the memory heap using WinDbg and all paths lead to the IronPython.Objects.Frame. All the variables that I passed to the PythonEngine are kept in the dictionary inside these Frames. These Frames in turn are kept in some static object[] array.
>In attached project I run in a loop some trivial script using engine Execute method. You can attach to it using WinDbg and check that after the loop completes there are 100 instances of Frame. Here is one sample from the gcroot command:
>0:003> !gcroot 00b37918
>Note: Roots found on stacks may be false positives. Run "!help gcroot" for more info.
>Scan Thread 0 OSTHread 13dc
>Scan Thread 2 OSTHread 17fc
>I also tried this with the evaluate method and the effect was the same.
>Only with (my favorite) FastEval option the memory is not allocated. So this could mean this leak occurs during code generation.
>I hope this is something that can be fixed quickly as we need to deploy this solution to production.
>Note: I still work on .NET Beta 2 and IronPython 0.9.3. I also run the test on the 0.9.4 version but results were the same.
>Thanks in Advance,
>Szymon Kobalczyk.
>PS: I post this mail again cause previously it had to large attachment and was held for approval by moderator.


	Software Mind 	
*Software Mind Sp z oo*
Bociana 22A
31-231 Kraków
Tel. (+48-12) 6145490
Fax: (+48-12) 6145170
s.kobalczyk at softwaremind.pl <mailto:s.kobalczyk at softwaremind.pl>
*Szymon Kobalczyk*
Software Developer

This email may contain confidential and privileged material for the sole 
use of the intended recipient(s). Any review, use, retention, 
distribution or disclosure by others is strictly prohibited. If you are 
not the intended recipient (or authorized to receive for the recipient), 
please contact the sender by reply email and delete all copies of this 
message. Also, email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive 
emails on the basis that we are not liable for any such corruption, 
interception, tampering, amendment or viruses or any consequence thereof.

More information about the Ironpython-users mailing list