https://bugs.kde.org/show_bug.cgi?id=464671
Bug ID: 464671
Summary: Default glibc suppression shouldn't use
@GLIBC_VERSION@ anymore with glibc >= 2.34
Classification: Developer tools
Product: valgrind
Version: 3.21 GIT
Platform: Other
OS: Other
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: romain.geiss...@amadeus.com
Target Milestone: ---
Hi,
I have investigated a valgrind false positive I had after upgrading my
toolchain. I have a gnu toolchain built from scratch, using glibc 2.37 (current
master branch) and a gcc 13, configured with --with-arch-64=x86-64-v2. It looks
like the resulting glibc also uses x86-64-v2 by default, and apparently uses
some vectorized instruction by default, especially in strcmp.
When running memcheck on a dynamically linked program, valgrind is actually
reporting two "cond" errors during the glibc startup, in stack traces like
this:
==16638== Conditional jump or move depends on uninitialised value(s)
==16638== at 0x40217E1: strcmp (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x400AD64: _dl_name_match_p (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x4008353: _dl_map_object (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x4019F94: map_doit (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x4001488: _dl_catch_exception (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x40015AE: _dl_catch_error (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x401A47F: do_preload (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x401B206: handle_preload_list (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x401E022: dl_main (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x401989E: _dl_sysdep_start (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x401AFAB: _dl_start (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== by 0x4019E77: ??? (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
==16638== Uninitialised value was created by a stack allocation
==16638== at 0x401B1AA: handle_preload_list (in
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23.0.4/lib/ld-linux-x86-64.so.2)
So while trying to LD_PRELOAD the valgrind strcmp symbol replacements, we call
the glibc strcmp, which causes some expected errors (most likely generated by
the vectorization code).
Checking the default suppression file, I can see things like:
{
dl-hack3-cond-1
Memcheck:Cond
obj:*/lib*/ld-2.36*.so*
obj:*/lib*/ld-2.36*.so*
obj:*/lib*/ld-2.36*.so*
}
However since glibc 2.34, these files ld-2.36*.so* no long exist. According to
glibc NEWS file:
* Previously, glibc installed its various shared objects under versioned
file names such as libc-2.33.so. The ABI sonames (e.g., libc.so.6)
were provided as symbolic links. Starting with glibc 2.34, the shared
objects are installed under their ABI sonames directly, without
symbolic links. This increases compatibility with distribution
package managers that delete removed files late during the package
upgrade or downgrade process.
Indeed comparing a glibc 2.23 vs 2.37, here is what we see for ld.so:
rgeissler@ncerndobedev6097:~> ls -la
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4/lib*|grep ld-
-rwxr-xr-x 1 otfdelde otfdelde 185520 Dec 19 14:36 ld-2.23.so
lrwxrwxrwx 1 otfdelde otfdelde 10 Dec 19 14:36 ld-linux-x86-64.so.2 ->
ld-2.23.so
rgeissler@ncerndobedev6097:~> ls -la
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v23/lib*|grep ld-
-rwxr-xr-x 1 otfdelde otfdelde 227256 Jan 16 22:15 ld-linux-x86-64.so.2
So the file glibc-2.X.supp.in in valgrind source code
https://sourceware.org/git/?p=valgrind.git;a=blob;f=glibc-2.X.supp.in;h=eeefa393519476120f6f0ce1320163b216339354;hb=HEAD
seems to be wrong for recent glibc. Would it be possible to edit it to take
into account the new glibc file naming convention ? I tried changing all
*/lib*/ld-2.36*.so* patterns by */lib*/ld-linux*.so* locally, and it worked (ie
valgrind didn't report any false positive anymore).
Cheers,
Romain
--
You are receiving this mail because:
You are watching all bug changes.
