[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