In private email, Mark Roberts wrote: > Thank you for your help. I have attached the requested files from my > primary machine - an intel i7-2600 based desktop system running > Linux(Fedora) 4.3.3-200.fc22.x86_64 with 16G memory.
Thank you for sending detailed information. I ran "make regtest" from valgrind-svn last night, on Fedora 22 x86_64. The summary: == 743 tests, 2 stderr failures, 1 stdout failure, 0 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hgtls (stdoutB) memcheck/tests/leak_cpp_interior (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) Looking at a couple of my *.diff files [excerpted and snipped aggressively]: ===== 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). ===== 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. Thus I believe that there is little cause for worry. -- ------------------------------------------------------------------------------ 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
