Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=80008 --- shadow/80008 2006-11-22 22:46:43.000000000 -0500 +++ shadow/80008.tmp.20927 2006-11-22 22:46:43.000000000 -0500 @@ -0,0 +1,50 @@ +Bug#: 80008 +Product: Mono: Class Libraries +Version: 1.2 +OS: +OS Details: +Status: NEW +Resolution: +Severity: +Priority: Normal +Component: CORLIB +AssignedTo: [EMAIL PROTECTED] +ReportedBy: [EMAIL PROTECTED] +QAContact: [EMAIL PROTECTED] +TargetMilestone: --- +URL: +Cc: +Summary: SoapFormatter consumes all memory + +Description of Problem: +SoapFormatter consumes memory. + +Steps to reproduce the problem: +Use SoapFormatter to serialize an array containing structs with private +members, Guids for example. (this will make the bug occur faster) + +Actual Results: +Steady growth in memory consumption until all memory is used up. + +Expected Results: +More-or-less constant memory usage (within normal fluctuations due to GC) + +How often does this happen? +Always. + +Additional Information: +System.Runtime.Remoting.InternalRemotingServices has a "cache" for soap +attributes. Unfortunately it is *not* a real cache, but rather a history +buffer that keeps both the keys and the objects alive indefinitely and +grows out of bounds (it merrily consumed the memory of our server, all 8GB +of it :)) + +The problem is further amplified by the code in +System.Runtime.Serialization.FormatterServices:GetFields where the fields +are cloned. Therefore - as far as I can see - there will never be a cache hit. + +Thus it seems to be safe to disable the cache as a temporary fix without +any performance issues. Works for me (TM) :D + +I have checked: 1.1.16 and 1.2.1 on x86-64 compiled with LARGE_CONFIG GC; +1.1.17 on i386 with standard GC _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
