Re: Question: bug in user code, valgrind or glibc?

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