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 
unchanged?

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

Szymon

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.
>
>Martin
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szymon Kobalczyk
>Sent: Friday, November 04, 2005 10:13 AM
>To: [email protected]
>Subject: [IronPython] Is this memory leak ?
>
>Hi,
>
>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
>DOMAIN(00153570):HANDLE(Pinned):9313e4:Root:01ab4480(System.Object[])->00b37918(IronPython.Objects.Frame)
>
>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
Poland
Tel. (+48-12) 6145490
Fax: (+48-12) 6145170
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
www.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.



_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to