Thank you for your help. I would like to double check the Valgrind version
related to this issue. I have these same failures on Fedora 22 and Ubuntu
15.10 – but I am using release version 3.11.0 and the date on 345307 is this
year. Sounds like I should retry running from the active svn trunk before
reporting any problems. Is there a particular revision I should sync to or
just take the current tree?
Thanks again,
Mark
From: Ivo Raisr [mailto:iv...@ivosh.net]
Sent: Friday, April 15, 2016 12:38 AM
To: John Reiser
Cc: Valgrind Users
Subject: Re: [Valgrind-users] expected results for regtest
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>
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
<https://bugs.kde.org/show_bug.cgi?id=345307> 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
