Re: [Valgrind-users] expected results for regtest

[Mark R. <ma...@cs...>]

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...@iv...] 
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 <jr...@bi...>:

===== 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.