<div dir="ltr">Hi,<div><br></div><div>  Fixed the last one in:</div><div><a href="https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7">https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7</a><br></div><div><br></div><div>The first two are leaks, but they should be small and bounded. Will look into fixing them to decrease the noise.</div><div><br></div><div>          Zoltan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 27, 2016 at 6:23 PM, Zinkevicius, Matt <span dir="ltr"><<a href="mailto:matt.zinkevicius@hpe.com" target="_blank">matt.zinkevicius@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p>Hello,<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>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.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>The vast majority of leaks reported have call stacks that closely match one of the following:<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>==16846== 4 bytes in 1 blocks are definitely lost in loss record 74 of 19,903<u></u><u></u></p>
<p>==16846==    at 0x4C26FEF: calloc (vg_replace_malloc.c:711)<u></u><u></u></p>
<p>==16846==    by 0x62D1D9: monoeg_malloc0 (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x4870F2: decode_exception_debug_info (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x488975: mono_aot_find_jit_info (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x53C3A7: mono_jit_info_table_find_internal (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x493C04: mini_jit_info_table_find_ext (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x4988FB: mini_add_method_trampoline (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x499067: common_call_trampoline_inner (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x403217C: ???<u></u><u></u></p>
<p>==16846==    by 0x10D3FB63: ???<u></u><u></u></p>
<p>==16846==    by 0x10D3F41B: ???<u></u><u></u></p>
<p>==16846==    by 0x10D3F117: ???<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>==16846== 12 bytes in 1 blocks are definitely lost in loss record 1,172 of 19,903<u></u><u></u></p>
<p>==16846==    at 0x4C2828A: malloc (vg_replace_malloc.c:299)<u></u><u></u></p>
<p>==16846==    by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x55B8EF: mono_metadata_type_dup (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x49FC4B: get_shared_gparam (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x49FE70: get_shared_inst (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x4A073A: mini_get_shared_method_full (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x414723: lookup_method (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x4147FA: mono_jit_compile_method_with_opt (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x414B9A: mono_jit_compile_method (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x498DA4: common_call_trampoline_inner (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x403405C: ???<u></u><u></u></p>
<p>==16846==    by 0x10D2DCA7: ???<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>==16846== 10 bytes in 1 blocks are definitely lost in loss record 739 of 19,903<u></u><u></u></p>
<p>==16846==    at 0x4C2828A: malloc (vg_replace_malloc.c:299)<u></u><u></u></p>
<p>==16846==    by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x62BA8C: monoeg_g_utf16_to_utf8 (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x5A8646: mono_string_to_utf8_checked (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x5A885B: mono_string_to_utf8 (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x52DE3C: ves_icall_Type_GetNestedTypes (in /usr/bin/mono-sgen)<u></u><u></u></p>
<p>==16846==    by 0x120D4256: ???<u></u><u></u></p>
<p>==16846==    by 0xE338A78: System_Type_GetMember_string_System_Reflection_BindingFlags (type.cs:806)<u></u><u></u></p>
<p>==16846==    by 0x40C09EF: ???<u></u><u></u></p>
<p>==16846==    by 0x1259A6AF: ???<u></u><u></u></p>
<p>==16846==    by 0x73: ???<u></u><u></u></p>
<p>==16846==    by 0x141D191D: ???<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Are these valid leaks or is valgrind confused/misconfigured? I am using the following command:<u></u><u></u></p>
<p>valgrind --tool=memcheck -v --leak-check=full --log-file=val.txt --smc-check=all mono program.exe<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Thanks for any input you can offer,<u></u><u></u></p>
<p>Matt Zinkevicius<u></u><u></u></p>
<p><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" rel="noreferrer" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div>