Hi there,
Thank you for analysing the situation.
Let me clarify things a bit...
2016-04-15 2:56 GMT+02:00 John Reiser <jrei...@bitwagon.com>:
> =====
> memcheck/tests/leak_cpp_interior/leak_cpp_interior.stderr.diff-64bit
> (stderr)
> - still reachable: 239 bytes in 8 blocks
> + still reachable: 72,943 bytes in 9 blocks
>
> This is a change that is internal to glibc, perhaps something related to
> locale tables. From memcheck's point of view, the external environment
> has changed (using glibc-2.21-13.fc22.x86_64).
>
This has to do with a change in libstdc++, not glibc.
If the program is linked with libstdc++ from gcc 5.x or higher,
then libstdc++ allocates a block for so called "emergency pool".
This skews the results we expect.
Although https://bugs.kde.org/show_bug.cgi?id=345307 fixed
what could be called a false memory leak, the memory block is still
being allocated during the program run.
This particular test case performs incremental leak check analysis
and therefore it does not benefit from fix for 345307
<https://bugs.kde.org/show_bug.cgi?id=345307>.
A solution could be to write a filter.
>
> ===== massif/tests/new-cpp.post.diff (post)
> - 1 4,008 4,008 4,000 8
> 0
> - 2 8,016 8,016 8,000 16
> 0
> - 3 10,024 10,024 10,000 24
> 0
> - 4 12,032 12,032 12,000 32
> 0
> - 5 12,032 12,032 12,000 32
> 0
> -99.73% (12,000B) (heap allocation functions) malloc/new/new[],
> --alloc-fns, etc.
> -->33.24% (4,000B) 0x........: main (new-cpp.cpp:19)
> + 1 72,712 72,712 72,704 8
> 0
> + 2 76,720 76,720 76,704 16
> 0
> + 3 80,728 80,728 80,704 24
> 0
> + 4 82,736 82,736 82,704 32
> 0
> + 5 84,744 84,744 84,704 40
> 0
> + 6 84,744 84,744 84,704 40
> 0
> +99.95% (84,704B) (heap allocation functions) malloc/new/new[],
> --alloc-fns, etc.
> +->85.79% (72,704B) 0x........: ??? (in /usr/lib64/libstdc++.so.6.0.21)
> +| ->85.79% (72,704B) 0x........: call_init.part.0 (dl-init.c:72)
> +| ->85.79% (72,704B) 0x........: _dl_init (dl-init.c:30)
> +| ->85.79% (72,704B) 0x........: ??? (in /usr/lib64/ld-2.21.so)
> +|
> +->04.72% (4,000B) 0x........: main (new-cpp.cpp:19)
>
> I believe that this change in output from massif has the same underlying
> cause
> as the change above in the output from memcheck.
>
Agreed. I tried to fix this in bug 345307 ignoring allocations
done by _GLOBAL__sub_I_eh_alloc.cc. This worked for Linux/Ubuntu 15.10
and Solaris 12. Apparently on this distribution, things are a bit different
so another
function needs to be ignored. A little investigation should show what needs
to be done here.
Please raise corresponding bugs for these. Patches welcome!
I.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
