[Mono-dev] Leaky JIT while running MonoDevelop

Casey Marshall casey.s.marshall at gmail.com
Wed Aug 20 18:26:23 EDT 2008


Rodrigo Kumpera wrote:
> 
> 
> On Tue, Aug 19, 2008 at 9:53 PM, Casey Marshall 
> <casey.s.marshall at gmail.com <mailto:casey.s.marshall at gmail.com>> wrote:
> 
>     On Tue, Aug 19, 2008 at 5:34 AM, Rodrigo Kumpera <kumpera at gmail.com
>     <mailto:kumpera at gmail.com>> wrote:
>      > Hi,
>      >
>      > I spent a few hours yesterday trying to reproduce your bug
>     without success.
>      > I have to say that from your valgrind result, the issue is
>     closely related
>      > to how
>      > your perforce library interact with unmanaged code - it happens
>     when you
>      > pass a delegate to a pinvoke and somehow memory is leaked.
>      >
> 
>     Yeah, I'm willing to believe I'm doing something wrong with the
>     pointer-to-delegate handling, but it's also unfortunately not the
>     whole story -- it still leaks memory if I disable that code.
>     Valgrind's choosy about what it reports, I think, and I get different
>     leak reports on different runs, so it's super-hard to tell what the
>     underlying problem(s) is(/are).
> 
> 
> 
> You can keep posting then as it should eventually pinpoint the culprit.
> One thing that helps is to enable valgrind support in the runtime. Just
> install the -devel package from your distro and reconfigure mono.
> 

I think I've figured this out, though. The issue was probably because 
the swig code generates a C++ object that refers to a C# object (via 
delegates), and the C# object refers directly to the C++ object. So, it 
seems, the C# object is never collected. Calling dispose on the object 
(which releases the C++ object) should fix this.

A little test case that explicitly disposes of the offending C# class 
seems to solve that leak. I'm still seeing MonoDevelop's memory usage 
creep upward, though, so I'll keep looking. It seems like this kind of 
bug might be common in a lot of code (e.g., Gtk#) that MonoDevelop uses.

Thanks.


More information about the Mono-devel-list mailing list