This is a collection of the current failures of the testsuite. We might consider some (or all) of them safe, but they deserve proper inspection in any case.

s390x:

drd/tests/tc04_free_lock
This is a minor mismatch in the expected backtrace vs real output.

=================================================
drd/tests/tc04_free_lock.stderr.diff-s390
=================================================
--- tc04_free_lock.stderr.exp-s390      2024-04-26 12:47:42.000000000 -0400
+++ tc04_free_lock.stderr.out   2024-05-10 08:52:13.080500194 -0400
@@ -8,7 +8,7 @@

 Destroying locked mutex: mutex 0x........, recursion count 1, owner 1.
    at 0x........: bar (tc04_free_lock.c:40)
-   by 0x........: ???
+   by 0x........: ??? (in /root/rpmbuild/BUILD/valgrind-3.23.0/helgrind/tests/tc04_free_lock)
 mutex 0x........ was first observed at:
    at 0x........: pthread_mutex_lock (drd_pthread_intercepts.c:?)
    by 0x........: bar (tc04_free_lock.c:38)
@@ -16,7 +16,7 @@

 Destroying locked mutex: mutex 0x........, recursion count 1, owner 1.
    at 0x........: foo (tc04_free_lock.c:49)
-   by 0x........: ???
+   by 0x........: ??? (in /root/rpmbuild/BUILD/valgrind-3.23.0/helgrind/tests/tc04_free_lock)
 mutex 0x........ was first observed at:
    at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
    by 0x........: foo (tc04_free_lock.c:46)

ppc64le

memcheck/tests/linux/rfcomm
This is an old known issue. The expected is a frame in the test source, but instead points to glibc's bind, FTR, this line https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bind.c;h=630b452e2ac2fad57b1fad9dab9d722442aa1ebc;hb=ef321e23c20eebc6d6fb4044425c00e6df27b05f#l23. It was reviewed back in the day https://bugzilla.redhat.com/show_bug.cgi?id=1652512#c2 but it's still worth listing it here.

--- rfcomm.stderr.exp	2024-04-26 12:47:42.000000000 -0400
+++ rfcomm.stderr.out	2024-05-10 09:12:46.608034904 -0400
@@ -2,7 +2,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (bind.c:23)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)

@@ -10,7 +10,7 @@
    ...
    by 0x........: main (rfcomm.c:53)
  Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (bind.c:23)
  Uninitialised value was created by a client request
    at 0x........: main (rfcomm.c:45)

<truncated beyond 20 lines>

helgrind/tests/getaddrinfo
We haven't seen this one before, the test was added in 3.22. The test reports a data
race in a segment mapped by libnss_myhostname.so.2:

--- getaddrinfo.stderr.exp      2024-04-26 12:47:42.000000000 -0400
+++ getaddrinfo.stderr.out      2024-05-13 08:00:21.960583800 -0400
@@ -0,0 +1,21 @@
+---Thread-Announcement------------------------------------------
+
+Thread #x was created
+   ...
+   by 0x........: pthread_create@* (hg_intercepts.c:...)
+   by 0x........: main (getaddrinfo.c:33)
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in a r-- mapped file /usr/lib64/libnss_myhostname.so.2 segment
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+   ...
+ Address 0x........ is in a r-- mapped file /usr/lib64/libnss_myhostname.so.2 segment
+

We haven't reproduced it in rhel 9.5 which ships systemd-libs-252-33.el9 vs systemd-libs-255.3-1.el10. Interestingly, when installing the debug info of systemd-libs to see where the race occurs, this is what happens (run first w/o debuginfo, then w/ debuginfo):

# valgrind --tool=helgrind helgrind/tests/getaddrinfo
==23650== Helgrind, a thread error detector
==23650== Copyright (C) 2007-2024, and GNU GPL'd, by OpenWorks LLP et al.
==23650== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==23650== Command: helgrind/tests/getaddrinfo
==23650==
==23650== ---Thread-Announcement------------------------------------------
==23650==
==23650== Thread #5 was created
==23650==    at 0x4AACB00: clone (clone.S:86)
==23650==    by 0x4AACDD3: __clone_internal_fallback (clone-internal.c:64)
==23650==    by 0x4AACDD3: __clone_internal (clone-internal.c:109)
==23650==    by 0x4A047AF: pthread_create@@GLIBC_2.34 (pthread_create.c:836)
==23650==    by 0x48FFA8B: pthread_create_WRK (hg_intercepts.c:445)
==23650==    by 0x490150B: pthread_create@* (hg_intercepts.c:478)
==23650==    by 0x19039B: main (getaddrinfo.c:33)
==23650==
==23650== ----------------------------------------------------------------
==23650==
==23650== Possible data race during read of size 1 at 0x80502D0 by thread #5
==23650== Locks held: none
==23650==    at 0x4903A0C: strlen (vg_replace_strmem.c:505)
==23650==  Address 0x80502d0 is in a r-- mapped file /usr/lib64/libnss_myhostname.so.2 segment
==23650==
==23650== ----------------------------------------------------------------
==23650==
==23650== Possible data race during read of size 1 at 0x80502D1 by thread #5
==23650== Locks held: none
==23650==    at 0x4903A24: strlen (vg_replace_strmem.c:505)
==23650==  Address 0x80502d1 is in a r-- mapped file /usr/lib64/libnss_myhostname.so.2 segment
==23650==
==23650==
==23650== Use --history-level=approx or =none to gain increased speed, at
==23650== the cost of reduced accuracy of conflicting-access information
==23650== For lists of detected and suppressed errors, rerun with: -s
==23650== ERROR SUMMARY: 33 errors from 2 contexts (suppressed: 1176 from 159)
# debuginfo-install -yq systemd-libs

Installed:
  systemd-debuginfo-255.3-1.el10.ppc64le     systemd-libs-debuginfo-255.3-1.el10.ppc64le

# valgrind --tool=helgrind helgrind/tests/getaddrinfo
==23672== Helgrind, a thread error detector
==23672== Copyright (C) 2007-2024, and GNU GPL'd, by OpenWorks LLP et al.
==23672== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==23672== Command: helgrind/tests/getaddrinfo
==23672==
==23672==
==23672== Use --history-level=approx or =none to gain increased speed, at
==23672== the cost of reduced accuracy of conflicting-access information
==23672== For lists of detected and suppressed errors, rerun with: -s
==23672== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1289 from 166)
#

aarch64

memcheck/tests/linux/stack_changes
This test fails because valgrind prints lots of invalid writes. It seems to be triggered by the updated glibc, as we've seen this one also in Fedora 40/41 updates (glibc 2.39) but we did not see it in RHEL-9 (glibc-2.34).

The output printed from the build log is not very helpful, here's a complete output without stripped lines and glibc debuginfo:

# valgrind  memcheck/tests/linux/stack_changes
==124832== Memcheck, a memory error detector
==124832== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==124832== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==124832== Command: memcheck/tests/linux/stack_changes
==124832==
hello, world: 0
hello, world: 1
==124832== Invalid write of size 8
==124832==    at 0x496AD78: printf (printf.c:28)
==124832==  Address 0x4b06f10 is on thread 1's stack
==124832==
==124832== Invalid write of size 8
==124832==    at 0x496AD8C: printf (printf.c:28)
==124832==  Address 0x4b06f20 is on thread 1's stack
==124832==
==124832== Invalid write of size 8
==124832==    at 0x496AD90: printf (printf.c:28)
==124832==  Address 0x4b06f30 is on thread 1's stack
==124832==
==124832== Invalid write of size 8
==124832==    at 0x496AD94: printf (printf.c:28)
==124832==  Address 0x4b06f40 is on thread 1's stack
==124832==

[[ Same error over and over, for the sake of simplicity I'm cutting those down ]]

==124832== Invalid write of size 8
==124832==    at 0x496ADE0: printf (printf.c:32)
==124832==  Address 0x4b06ef8 is on thread 1's stack
==124832==
==124832== Invalid write of size 4
==124832==    at 0x496ADE4: printf (printf.c:32)
==124832==  Address 0x4b06f00 is on thread 1's stack
==124832==
==124832== Invalid read of size 16
==124832==    at 0x496ADE8: printf (printf.c:33)
==124832==  Address 0x4b06ee8 is on thread 1's stack
==124832==
==124832== Invalid read of size 16
==124832==    at 0x496ADEC: printf (printf.c:33)
==124832==  Address 0x4b06ef8 is on thread 1's stack
==124832==
==124832== Invalid write of size 8
==124832==    at 0x496ADF0: printf (printf.c:33)
==124832==  Address 0x4b06ec0 is on thread 1's stack
==124832==
==124832== Invalid read of size 16
==124832==    at 0x49752A4: __vfprintf_internal (vfprintf-internal.c:1544)
==124832==    by 0x496ADF7: printf (printf.c:33)
==124832==    by 0x11854F: hello (stack_changes.c:20)
==124832==    by 0x495AABF: ??? (setcontext.S:142)
==124832==  Address 0x4b06ec0 is on thread 1's stack
==124832==  in frame #1, created by printf (printf.c:28)
==124832==
==124832== Invalid read of size 4
==124832==    at 0x4975018: __printf_buffer (vfprintf-process-arg.c:53)
==124832==    by 0x49752C3: __vfprintf_internal (vfprintf-internal.c:1544)
==124832==    by 0x496ADF7: printf (printf.c:33)
==124832==    by 0x11854F: hello (stack_changes.c:20)
==124832==    by 0x495AABF: ??? (setcontext.S:142)
==124832==  Address 0x4b06fa8 is on thread 1's stack
==124832==  in frame #2, created by printf (printf.c:28)
==124832==
hello, world: 2
==124832== Invalid read of size 8
==124832==    at 0x496AE00: printf (printf.c:37)
==124832==  Address 0x4b06f08 is on thread 1's stack
==124832==
==124832== Invalid read of size 8
==124832==    at 0x496AE14: printf (printf.c:37)
==124832==  Address 0x4b06f10 is on thread 1's stack
==124832==
==124832==
==124832== HEAP SUMMARY:
==124832==     in use at exit: 0 bytes in 0 blocks
==124832==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==124832==
==124832== All heap blocks were freed -- no leaks are possible
==124832==
==124832== For lists of detected and suppressed errors, rerun with: -s
==124832== ERROR SUMMARY: 43 errors from 24 contexts (suppressed: 0 from 0)

Aside from that failure the ones listed from this point are already well known since RHEL-8, reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=1652488#c3

rhn-engineering-mjw the output of these remained consistent from RHEL-8 to RHEL-10. Do you think it's worth adding some aarch64-specific exp files for these?

• gdbserver_tests/hgtls

  --- hgtls.stdoutB.exp	2024-04-26 16:47:42.000000000 +0000
  +++ hgtls.stdoutB.out	2024-05-10 10:29:48.519794317 +0000
  @@ -8,38 +8,9 @@
   test race tls_ip 0x........ ip 0x........ equal 1
   Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
   55		int here = 0;
  -test local tls_ip 0x........ ip 0x........ equal 1
  -Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
  -55		int here = 0;
  -test local tls_ip 0x........ ip 0x........ equal 1
  -Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
  -55		int here = 0;
  -test global tls_ip 0x........ ip 0x........ equal 1
  -Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
  -55		int here = 0;
  -test global tls_ip 0x........ ip 0x........ equal 1
  -Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
  -55		int here = 0;
  -test static_extern tls_ip 0x........ ip 0x........ equal 1
  -Breakpoint 1, tls_ptr (p=0x........) at tls.c:55
  <truncated beyond 20 lines>
  

• memcheck/tests/dw4

  --- dw4.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ dw4.stderr.out	2024-05-10 10:31:06.220414537 +0000
  @@ -14,8 +14,8 @@
   Uninitialised byte(s) found during client check request
      at 0x........: croak (dw4.c:32)
      by 0x........: main (dw4.c:62)
  - Location 0x........ is 0 bytes inside local.i,
  - declared at dw4.c:51, in frame #1 of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #1, created by main (dw4.c:50)
  
   Uninitialised byte(s) found during client check request
      at 0x........: croak (dw4.c:32)
  

• memcheck/tests/varinfo2

  --- varinfo2.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ varinfo2.stderr.out	2024-05-10 10:34:12.101898276 +0000
  @@ -2,20 +2,20 @@
      at 0x........: croak (varinfo2.c:28)
      by 0x........: foo (varinfo2.c:41)
      by 0x........: main (varinfo2.c:51)
  - Location 0x........ is 0 bytes inside var[7],
  - declared at varinfo2.c:39, in frame #X of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #X, created by foo (varinfo2.c:36)
  
   Uninitialised byte(s) found during client check request
      at 0x........: croak (varinfo2.c:28)
      by 0x........: foo (varinfo2.c:43)
      by 0x........: main (varinfo2.c:51)
  - Location 0x........ is 2 bytes inside var.bar,
  - declared at varinfo2.c:42, in frame #X of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #X, created by foo (varinfo2.c:36)
  

• memcheck/tests/varinfo4

  --- varinfo4.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ varinfo4.stderr.out	2024-05-10 10:34:14.091914161 +0000
  @@ -2,20 +2,20 @@
      at 0x........: croak (varinfo4.c:28)
      by 0x........: blah (varinfo4.c:47)
      by 0x........: main (varinfo4.c:56)
  - Location 0x........ is 1 byte inside a[3].xyzzy[21].c1,
  - declared at varinfo4.c:45, in frame #1 of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #1, created by blah (varinfo4.c:44)
  
   Uninitialised byte(s) found during client check request
      at 0x........: croak (varinfo4.c:28)
      by 0x........: blah (varinfo4.c:48)
      by 0x........: main (varinfo4.c:56)
  - Location 0x........ is 0 bytes inside a[5].bong,
  - declared at varinfo4.c:45, in frame #1 of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #1, created by blah (varinfo4.c:44)
  

• memcheck/tests/varinfo5

  --- varinfo5.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ varinfo5.stderr.out	2024-05-10 10:34:15.111922302 +0000
  @@ -46,8 +46,8 @@
      by 0x........: varinfo1_main (tests/varinfo5so.c:59)
      by 0x........: varinfo5_main (tests/varinfo5so.c:154)
      by 0x........: main (tests/varinfo5.c:5)
  - Location 0x........ is 0 bytes inside local var "local"
  - declared at varinfo5so.c:49, in frame #X of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #X, created by varinfo1_main (varinfo5so.c:48)
  
   Uninitialised byte(s) found during client check request
      at 0x........: croak (tests/varinfo5so.c:29)
  @@ -55,8 +55,8 @@
      by 0x........: varinfo2_main (tests/varinfo5so.c:81)
      by 0x........: varinfo5_main (tests/varinfo5so.c:155)
      by 0x........: main (tests/varinfo5.c:5)
  - Location 0x........ is 0 bytes inside var[7],
  - declared at varinfo5so.c:69, in frame #X of thread 1
  + Address 0x........ is on thread 1's stack
  <truncated beyond 20 lines>
  

• memcheck/tests/varinfo6

  --- varinfo6.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ varinfo6.stderr.out	2024-05-10 10:34:16.431932839 +0000
  @@ -7,8 +7,8 @@
      by 0x........: BZ2_bzCompress (varinfo6.c:4860)
      by 0x........: BZ2_bzBuffToBuffCompress (varinfo6.c:5667)
      by 0x........: main (varinfo6.c:6517)
  - Location 0x........ is 2 bytes inside local var "budget"
  - declared at varinfo6.c:3115, in frame #2 of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #2, created by BZ2_blockSort (varinfo6.c:3107)
  
   Uninitialised byte(s) found during client check request
      at 0x........: croak (varinfo6.c:34)
  @@ -16,6 +16,6 @@
      by 0x........: BZ2_bzDecompress (varinfo6.c:5230)
      by 0x........: BZ2_bzBuffToBuffDecompress (varinfo6.c:5715)
      by 0x........: main (varinfo6.c:6532)
  - Location 0x........ is 2 bytes inside local var "i"
  - declared at varinfo6.c:1517, in frame #1 of thread 1
  + Address 0x........ is on thread 1's stack
  <truncated beyond 20 lines>
  

• memcheck/tests/varinforestrict

  --- varinforestrict.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ varinforestrict.stderr.out	2024-05-10 10:34:17.421940741 +0000
  @@ -3,6 +3,6 @@
      at 0x........: croak (varinforestrict.c:25)
      by 0x........: bad_restrict_ptr (varinforestrict.c:33)
      by 0x........: main (varinforestrict.c:56)
  - Location 0x........ is 0 bytes inside local var "bad_ptr"
  - declared at varinforestrict.c:31, in frame #1 of thread 1
  + Address 0x........ is on thread 1's stack
  + in frame #1, created by bad_restrict_ptr (varinforestrict.c:32)
  

• helgrind/tests/hg05_race2

  --- hg05_race2.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ hg05_race2.stderr.out	2024-05-10 10:35:20.452443862 +0000
  @@ -26,8 +26,8 @@
      at 0x........: th (hg05_race2.c:17)
      by 0x........: mythread_wrapper (hg_intercepts.c:...)
      ...
  - Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
  - declared at hg05_race2.c:24, in frame #x of thread x
  + Address 0x........ is on thread #x's stack
  + in frame #x, created by main (hg05_race2.c:23)
  

• helgrind/tests/tc20_verifywrap

  --- tc20_verifywrap.stderr.exp	2024-04-26 16:47:42.000000000 +0000
  +++ tc20_verifywrap.stderr.out	2024-05-10 10:36:01.002767542 +0000
  @@ -169,8 +169,8 @@
      at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
      by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
      by 0x........: main (tc20_verifywrap.c:193)
  - Location 0x........ is 0 bytes inside local var "rwl"
  - declared at tc20_verifywrap.c:57, in frame #x of thread x
  + Address 0x........ is on thread #x's stack
  + in frame #x, created by main (tc20_verifywrap.c:49)
  
  
   (1) no error on next line
  @@ -187,8 +187,8 @@
      at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
      by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
      by 0x........: main (tc20_verifywrap.c:201)
  - Location 0x........ is 0 bytes inside local var "rwl2"
  - declared at tc20_verifywrap.c:58, in frame #x of thread x
  + Address 0x........ is on thread #x's stack
  <truncated beyond 20 lines>