[MonoDevelop] Memory leak

[Casey Marshall]

Michael Hutchinson wrote:
> On Wed, Aug 13, 2008 at 7:20 PM, Casey Marshall
> <casey.s.marshall at gmail.com> wrote:
>>>>> ==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.
> 
> Yup, the fact that the trace goes through some JIT compilation methods
> makes me suspect that it's leaking JITed code. I guess we should
> really talk to some runtime guys though. Also, MD dynamically compiles
> and load some code (e.g.
> MonoDevelop.Core.Gui.DispatchService/SyncContext does this, not sure
> if there's anything else, maybe remoting too?) and though the
> generated should be cached per Type, I guess there could be leaking
> problems...
> 

Yeah, somehow MD is putting pressure on the JIT, and it's not reclaiming 
a lot of storage. I ran MD again overnight, this time with 
--optimization=-linears (this was where the original valgrind trace came 
from) and the memory usage grew much more slowly. The big-huge trace I 
found in the valgrind output this morning was a different location in 
the JIT:

> ==5807== 794,797,632 bytes in 1,601,948 blocks are still reachable in loss record 238 of 238
> ==5807==    at 0x4C21F8F: memalign (vg_replace_malloc.c:460)
> ==5807==    by 0x4C22028: posix_memalign (vg_replace_malloc.c:569)
> ==5807==    by 0x507D299: (within /usr/lib/libglib-2.0.so.0.1600.4)
> ==5807==    by 0x507E0F0: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.4)
> ==5807==    by 0x506035D: g_list_prepend (in /usr/lib/libglib-2.0.so.0.1600.4)
> ==5807==    by 0x52AF25: mono_allocate_stack_slots_full (mini.c:9812)
> ==5807==    by 0x432320: mono_arch_allocate_vars (mini-amd64.c:1137)
> ==5807==    by 0x558127: mini_method_compile (mini.c:12525)
> ==5807==    by 0x559419: mono_jit_compile_method (mini.c:12836)
> ==5807==    by 0x42C5E2: mono_magic_trampoline (mini-trampolines.c:249)
> ==5807==    by 0x415B164: ???
> ==5807==    by 0x8BA4AAB: ???

I don't think valgrind captures absolutely everything, so the above 
might have contributed to the earlier case, too.

I'll send a message to the mono-devel list.

Thanks.