[Mono-bugs] [Bug 71001][Cri] Changed - xsp.exe virtual size grows without bound -- large messages

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Wed Jun 15 15:08:04 EDT 2005


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 matt.hargett at logiclibrary.com.

http://bugzilla.ximian.com/show_bug.cgi?id=71001

--- shadow/71001	2005-06-07 21:46:08.000000000 -0400
+++ shadow/71001.tmp.19252	2005-06-15 15:08:04.000000000 -0400
@@ -1,16 +1,16 @@
 Bug#: 71001
 Product: Mono: Runtime
 Version: unspecified
 OS: SLES 9
 OS Details: AMD-64
-Status: RESOLVED   
-Resolution: WONTFIX
+Status: REOPENED   
+Resolution: 
 Severity: Unknown
 Priority: Critical
-Component: misc
+Component: GC
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: jrodman at ximian-bugzilla.spamportal.net               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
@@ -170,6 +170,17 @@
 
 Oh, and, as that buffer is allocated when reading the request, if you
 set that limit too high, you will be subject to denial of service
 attacks by anyone that posts a big content length a few times...
 
 
+
+------- Additional Comments From matt.hargett at logiclibrary.com  2005-06-15 15:08 -------
+This leak actually happens even when transferring files as small as
+2KB, perhaps even smaller. This seems to toss out the idea that the
+problem is strictly related to large SOAP messages.
+
+Memory usage (RSS and virtual) will increase incrementally, plateau,
+and then increase incrementally again, plateau again, etc, etc. We
+were initially fooled by the second plateau, since it takes a few
+transfers to get it leaking again. All transfers are synchronous, btw,
+one after the other.


More information about the mono-bugs mailing list