[Mono-dev] Using valgrind with Mono

[Zinkevicius, Matt]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20160327/5e51ea32/attachment.html>