[Mono-list] Memory leak

[Alan McGovern]

Hi,

I found the issue. Turns out that MS.NET is hitting the boehm "Embarrassing
Failure Scenario", in particular part 3:

The problem is not limited to what is normally referred to as "conservative"
garbage collection. *It could also be caused by having the garbage collector
accidentally trace from a dead compiler-generated variable*, or by promoting
a queue element to a generation that is effectively not collected. This data
structure is safe only with a system that is carefully designed to prevent
any form of extra space retention (cf. [Appel?]).

If you compile the code without optimisations, it leaks indefinitely. If you
compile with optimisations, the compiler generated variable is being
optimised away and so it doesn't leak. So, as was stated before and as is
stated in the boehm docs, this issue is *not* limited to conservative
garbage collectors.

It looks like mono could *probably* avoid the issue if it's optimisation
pass was able to nuke the same dead variable. It'd be interesting to compare
the IL of the version which does not leak under mono with the version that
does leak and see what the difference is.

Alan.

On Sat, Feb 7, 2009 at 2:00 PM, Jon Harrop <jon at ffconsultancy.com> wrote:
> On Saturday 07 February 2009 13:47:01 you wrote:
>> Well, the code you pasted in your email is definitely leaking on my
>> system under MS.NET 3.5 x86. Did you paste the wrong code in your
>> email?
>
> No, I pasted the correct code in my e-mail and I compiled it with MS
Visual C#
> 2008 Express to run it on .NET.
>
> However, I just noticed that Mono only leaks if the code is compiled using
> Mono's C# compiler and *not* if you give Mono the assembly produced by MS
> Visual C#. Perhaps you did the opposite and tried to run the output of
Mono's
> C# compiler under .NET without recompiling the C# source code using MS'
> tools?
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20090207/35175df0/attachment-0001.html