The memory leak on mono_method_get_header was recently fixed in master.
On Mon, Mar 28, 2016 at 3:31 AM, Zinkevicius, Matt <matt.zinkevic...@hpe.com > wrote: > I can confirm that Zoltan’s fix does indeed remove any leak instances with > a call stack containing “ves_icall_Type_GetNestedTypes”, but unfortunately > that accounted for only 36 leak instances out of the 19,900 reported. > > > > I have filed a bug (https://bugzilla.xamarin.com/show_bug.cgi?id=39940) > and attached the latest valgrind output there. > > > > Thanks again for any help you can provide, > > Matt Zinkevicius > > > > *From:* mono-devel-list-boun...@lists.ximian.com [mailto: > mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Zinkevicius, Matt > *Sent:* Sunday, March 27, 2016 11:06 PM > *To:* Zoltan Varga <var...@gmail.com> > *Cc:* Straw, David (Storage) <david.st...@hpe.com>; > mono-devel-list@lists.ximian.com > > *Subject:* Re: [Mono-dev] Using valgrind with Mono > > > > Hi Zoltan, > > > > Thank you for investigating my findings. I will apply the fix you linked > to and report back. While I understand the other leaks are small, valgrind > reported over 19,000 instances of leaked memory in under 5 minutes of our > app running without load. > > > > Matt Zinkevicius > > > > *From:* Zoltan Varga [mailto:var...@gmail.com <var...@gmail.com>] > *Sent:* Sunday, March 27, 2016 4:45 PM > *To:* Zinkevicius, Matt <matt.zinkevic...@hpe.com> > *Cc:* mono-devel-list@lists.ximian.com; Straw, David (Storage) < > david.st...@hpe.com> > *Subject:* Re: [Mono-dev] Using valgrind with Mono > > > > Hi, > > > > Fixed the last one in: > > > https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7 > > > > The first two are leaks, but they should be small and bounded. Will look > into fixing them to decrease the noise. > > > > Zoltan > > > > On Sun, Mar 27, 2016 at 6:23 PM, Zinkevicius, Matt < > matt.zinkevic...@hpe.com> wrote: > > Hello, > > > > Our backend service running on Mono 4.2.2 on Linux is experiencing an > unmanaged memory leak. When running our stress tests for several hours, we > see the managed heap sit around 50 MB, while private memory keeps growing > until the process is killed because of OOM. I am therefore attempting to > use valgrind to find the culprit, but I am getting so many leaks detected > that I think many must be false positives, so I thought I would ask here > for some guidance about which are safe to suppress or any other valgrind + > mono tricks you can share. > > > > The vast majority of leaks reported have call stacks that closely match > one of the following: > > > > ==16846== 4 bytes in 1 blocks are definitely lost in loss record 74 of > 19,903 > > ==16846== at 0x4C26FEF: calloc (vg_replace_malloc.c:711) > > ==16846== by 0x62D1D9: monoeg_malloc0 (in /usr/bin/mono-sgen) > > ==16846== by 0x4870F2: decode_exception_debug_info (in > /usr/bin/mono-sgen) > > ==16846== by 0x488975: mono_aot_find_jit_info (in /usr/bin/mono-sgen) > > ==16846== by 0x53C3A7: mono_jit_info_table_find_internal (in > /usr/bin/mono-sgen) > > ==16846== by 0x493C04: mini_jit_info_table_find_ext (in > /usr/bin/mono-sgen) > > ==16846== by 0x4988FB: mini_add_method_trampoline (in > /usr/bin/mono-sgen) > > ==16846== by 0x499067: common_call_trampoline_inner (in > /usr/bin/mono-sgen) > > ==16846== by 0x403217C: ??? > > ==16846== by 0x10D3FB63: ??? > > ==16846== by 0x10D3F41B: ??? > > ==16846== by 0x10D3F117: ??? > > > > ==16846== 12 bytes in 1 blocks are definitely lost in loss record 1,172 of > 19,903 > > ==16846== at 0x4C2828A: malloc (vg_replace_malloc.c:299) > > ==16846== by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen) > > ==16846== by 0x55B8EF: mono_metadata_type_dup (in /usr/bin/mono-sgen) > > ==16846== by 0x49FC4B: get_shared_gparam (in /usr/bin/mono-sgen) > > ==16846== by 0x49FE70: get_shared_inst (in /usr/bin/mono-sgen) > > ==16846== by 0x4A073A: mini_get_shared_method_full (in > /usr/bin/mono-sgen) > > ==16846== by 0x414723: lookup_method (in /usr/bin/mono-sgen) > > ==16846== by 0x4147FA: mono_jit_compile_method_with_opt (in > /usr/bin/mono-sgen) > > ==16846== by 0x414B9A: mono_jit_compile_method (in /usr/bin/mono-sgen) > > ==16846== by 0x498DA4: common_call_trampoline_inner (in > /usr/bin/mono-sgen) > > ==16846== by 0x403405C: ??? > > ==16846== by 0x10D2DCA7: ??? > > > > ==16846== 10 bytes in 1 blocks are definitely lost in loss record 739 of > 19,903 > > ==16846== at 0x4C2828A: malloc (vg_replace_malloc.c:299) > > ==16846== by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen) > > ==16846== by 0x62BA8C: monoeg_g_utf16_to_utf8 (in /usr/bin/mono-sgen) > > ==16846== by 0x5A8646: mono_string_to_utf8_checked (in > /usr/bin/mono-sgen) > > ==16846== by 0x5A885B: mono_string_to_utf8 (in /usr/bin/mono-sgen) > > ==16846== by 0x52DE3C: ves_icall_Type_GetNestedTypes (in > /usr/bin/mono-sgen) > > ==16846== by 0x120D4256: ??? > > ==16846== by 0xE338A78: > System_Type_GetMember_string_System_Reflection_BindingFlags (type.cs:806) > > ==16846== by 0x40C09EF: ??? > > ==16846== by 0x1259A6AF: ??? > > ==16846== by 0x73: ??? > > ==16846== by 0x141D191D: ??? > > > > Are these valid leaks or is valgrind confused/misconfigured? I am using > the following command: > > valgrind --tool=memcheck -v --leak-check=full --log-file=val.txt > --smc-check=all mono program.exe > > > > Thanks for any input you can offer, > > Matt Zinkevicius > > > > > > > _______________________________________________ > Mono-devel-list mailing list > 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 > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
