Oh, but: oof. I'm actually pretty sure this isn't in the JIT, but it's just getting blamed on the JIT because it's allocating things via glib -- those allocations are cached, and probably whatever is really leaking is just reusing the GList memory originally allocated by the JIT.
Rodrigo Kumpera wrote: > Hi Casey, > > We did a lot of work fixing many kinds of memory leaks under the runtime > and JIT. > There are a few know issues, but none that would show in valgrind like > this. And none > that would leak that much. > > I'll take a look at this issue in the comming days to see if I can > narrow it down. > > In the mean time, do you mind sending the whole valgrind report? > > Thanks, > Rodrigo > > On Thu, Aug 14, 2008 at 3:07 PM, Casey Marshall > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > I've been seeing a memory leak -- or, maybe instead, "unbounded memory > growth" -- while running MonoDevelop (SVN code of MD, mono-2-0 SVN of > Mono). I've been running it under valgrind, and after running it > overnight, I find traces like this in the output: > > > ==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: ??? > > (there are many other traces, but they're all two orders of magnitude > smaller, in terms of memory size) > > I ran the same test again, this time with --optimize=-linears (which is > where at least the above trace came from) and without --debug, and > memory still grew, but not quite as quickly. I got another valgrind > trace out of that run: > > > ==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 think valgrind just didn't capture this one the first time, but it was > a factor in the memory growth. > > I suppose that because MonoDevelop uses a fair amount of dynamic code, > it uses the JIT a lot, which seems to be provoking this. I personally > can't figure out why this memory is still reachable -- these are all > GLists, and it looks like they are passed to g_list_free at the end. I > suppose either some nodes are being lost after sorting, or something > more subtle is going on. > > This is glib version 2.16.4-0ubuntu2, on Ubuntu 8.04, amd64. > > Thanks. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > <mailto:Mono-devel-list@lists.ximian.com> > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list