[Mono-dev] Leaky JIT while running MonoDevelop
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.
More information about the Mono-devel-list