[MonoDevelop] Memory leak

[Casey Marshall]

Michael Hutchinson wrote:
> On Wed, Aug 13, 2008 at 3:50 PM, Casey Marshall
> <casey.s.marshall at gmail.com> wrote:
>> Mike Krüger wrote:
>>> Hi
>>>
>>> Yes, we're aware of memory problems and working on fixing them.
>>>
>>> Regards
>>> Mike
>>>
>>>> I think I've seen references to this before, but it looks like
>>>> MonoDevelop has a somewhat slow, but constant, memory leak. Are you guys
>>>> aware of this? Does anyone have an inkling on where it could be? The
>>>> leak seems pretty slow -- the heap grows by about 100K every two seconds
>>>> -- but it's constantly going up at that rate.
>>>>
>>>> I've tried running MonoDevelop both using heap-shot and valgrind, and
>>>> neither one seems to be pointing to any obvious issues, at least not
>>>> after a few hours.
>>>>
>>>> Thanks.
>> WRT that, though, any clue why I'm getting this result running
>> MonoDevelop under valgrind? 822 MiB is a pretty sizable percentage of
>> the memory MonoDevelop accumulated overnight:
>>
>>> ==7947== 862,223,392 bytes in 1,737,838 blocks are still reachable in loss record 238 of 238
>>> ==7947==    at 0x4C21F8F: memalign (vg_replace_malloc.c:460)
>>> ==7947==    by 0x4C22028: posix_memalign (vg_replace_malloc.c:569)
>>> ==7947==    by 0x507D299: (within /usr/lib/libglib-2.0.so.0.1600.4)
>>> ==7947==    by 0x507E0F0: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.4)
>>> ==7947==    by 0x506035D: g_list_prepend (in /usr/lib/libglib-2.0.so.0.1600.4)
>>> ==7947==    by 0x432953: mono_arch_get_allocatable_int_vars (mini-amd64.c:910)
>>> ==7947==    by 0x5579A9: mini_method_compile (mini.c:12490)
>>> ==7947==    by 0x558CF8: mono_jit_compile_method (mini.c:12819)
>>> ==7947==    by 0x42C5A2: mono_magic_trampoline (mini-trampolines.c:249)
>>> ==7947==    by 0x415B164: ???
>>> ==7947==    by 0x8FCA917: ???
>>> ==7947==    by 0x85E7E9F: ???
> 
> Am not familiar with valgrind output. What does this mean? Is it
> possible to see what's being leaked?
> 

The above is an example of one of the traces valgrind outputs (it's also 
by far the largest in terms of bytes); that is the amount of storage 
lost (though, not *exactly* lost in this case, since there are still 
apparently-active references to that data) and the trace where the bytes 
were allocated from.

> If that's the stack trace of the leak, it looks like a JIT leak to me
> (not that I have any real idea). This may be more likely when Mono's
> in debug mode (which "make run" uses). Can you repro this in release
> mode and/or Mono from the 2.0?
> 

I'll try it in release mode. I'm currently running this under SVN mono 
from the 2.0 branch.