Hi,
On Sat, May 21, 2022 at 02:42:22AM -0700, John Reiser wrote:
> > 143:39.43 GECKO(115765) ==115769== Invalid read of size 8
> > 143:39.64 GECKO(115765) ==115769== at 0x4021BF4: strncmp (strcmp.S:175)
> > 143:39.64 GECKO(115765) ==115769== by 0x400655D: is_dst
> > (dl-load.c:214)
>
> This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2:
> =====
> diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
> index 3b42b3a87..8272a3ae7 100644
> --- a/shared/vg_replace_strmem.c
> +++ b/shared/vg_replace_strmem.c
> @@ -710,6 +710,7 @@ static inline void my_exit ( int x )
> STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
> STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
> STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
> + STRNCMP("ld-linux*.so*", strncmp)
>
> #elif defined(VGO_freebsd)
> STRNCMP(VG_Z_LIBC_SONAME, strncmp)
This looks like https://bugs.kde.org/show_bug.cgi?id=434764
iconv_open causes ld.so v2.28+ to use optimised strncmp
Which was recently (but after 3.19.0) fixed by merging this commit:
commit 947388eb043ea1c44b37df94046e1eee790ad776
Author: Mike Crowe <[email protected]>
AuthorDate: Mon Sep 9 14:16:16 2019 +0100
Commit: Mark Wielaard <[email protected]>
CommitDate: Sat May 14 00:41:18 2022 +0200
Intercept strncmp for glibc ld.so v2.28+
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
valgrind to complain about glibc's highly-optimised strncmp performing
sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
ld.so too so we use valgrind's simple version to avoid this problem.
Cheers,
Mark
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
