[Mono-list] Mono memory usage grows but application memory looks stable
Manuel C.
wtesto at zero.undo.it
Mon Sep 28 13:24:47 EDT 2009
Sorry for the late response.
I tried also version 2.4.2.3, it's the same. I took me a few days to find
out that a missing Close() on a GZipStream was the root of all evil. Here is
an example:
static void Decompress()
{
byte[] file = File.ReadAllBytes("in.dat.gz");
Stream stream = new GZipStream(new MemoryStream(file),
CompressionMode.Decompress);
byte[] buffer = new byte[1024];
while (stream.Read(buffer, 0, buffer.Length) > 0);
// stream.Close();
}
A function similar to this is called very often in my application. Under
Windows with.Net there is no issue, but with Mono the memory usage will
increase with every call of Decompress(). I thought the deconstructor of the
stream will call the Close or Dispose method?
Greetings
Manuel
Chris Howie wrote:
>
> On Sun, Aug 2, 2009 at 4:52 PM, Manuel C.<wtesto at zero.undo.it> wrote:
>> "mono -V"
>> Mono JIT compiler version 1.9.1 (tarball)
>
> 1.9.1 is horribly ancient. I would not be surprised to find memory
> leak bugs. Try running with 2.4.2. It's relatively easy to backport
> the packages from squeeze to lenny.
>
> --
> Chris Howie
> http://www.chrishowie.com
> http://en.wikipedia.org/wiki/User:Crazycomputers
> _______________________________________________
> Mono-list maillist - Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
--
View this message in context: http://www.nabble.com/Mono-memory-usage-grows-but-application-memory-looks-stable-tp24782014p25649428.html
Sent from the Mono - General mailing list archive at Nabble.com.
More information about the Mono-list
mailing list