[Mono-dev] Using valgrind with Mono

[Zoltan Varga]

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.zinkevicius at 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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20160327/c0aa8825/attachment.html>