Mark:
The PowerPC test results for Valgrind 3.23.0.RC1
-----------------------------------------------------------
Power 10, Fedora release 38 :
memcheck/tests/linux/rfcomm (stderr) also fails for valgrind
3.21.0
helgrind/tests/getaddrinfo (stderr) did not fail for valgrind
3.21.0
drd/tests/std_thread2 (stderr) did not fail for valgrind
3.21.0
none/tests/socket_close (stderr) did not fail for valgrind
3.21.0
Note the following failed in valgrind 3.22.0:
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
but do not fail for Valgrind-3.23.0.RC1
----------------------------------------------------------------
Power 9LE, Ubuntu 20.04.6 LTS
Valgrind-3.23.0.RC1 failures:
memcheck/tests/leak_cpp_interior (stderr) Also failed for valgrind
3.22.0
memcheck/tests/linux/rfcomm (stderr) Also failed for valgrind
3.22.0
memcheck/tests/linux/sys-execveat (stderr) Also failed for valgrind
3.22.0
none/tests/fdleak_ipv4 (stderr) New failure, did not fail
for valgrind 3.22.0
none/tests/socket_close (stderr) New failure, did not fail
for valgrind 3.22.0
Note the following failed in valgrind 3.22.0:
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
but do not fail for Valgrind-3.23.0.RC1
----------------------------------------------------------------
Power 8LE, Ubuntu 20.04.6 LTS
Valgrind-3.23.0.RC1 failures:
memcheck/tests/leak_cpp_interior (stderr) Also failed for valgrind
3.22.0
memcheck/tests/linux/rfcomm (stderr) Also failed for valgrind
3.22.0
memcheck/tests/linux/sys-execveat (stderr) New failure, did not fail
for valgrind 3.22.0
none/tests/fdleak_ipv4 (stderr) New failure, did not fail
for valgrind 3.22.0
none/tests/socket_close (stderr) New failure, did not fail
for valgrind 3.22.0
Note the two failures from the previous valgrind -3.22.0
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/sys-execveat (stderr)
but do not fail for Valgrind-3.23.0.RC1
--------------------------------------------------------------------
Power 8BE, Red Hat Enterprise Linux Server release 7.9 (Maipo)
Valgrind-3.23.0.RC1 failures:
memcheck/tests/leak_cpp_interior (stderr) Also failed for valgrind
3.22.0
none/tests/fdleak_ipv4 (stderr) New failure, did not fail
for valgrind 3.22.0
none/tests/file_dclose (stderr) New failure, did not fail
for valgrind 3.22.0
none/tests/socket_close (stderr) New failure, did not fail
for valgrind 3.22.0
Note the failure from the previous valgrind -3.22.0
memcheck/tests/bug340392 (stderr)
do not fail for Valgrind-3.23.0.RC1
--------------------------------------------------------------------------
So, seeing very consistent results across distros and PowerPC processor
versions.
The diff for the four failures on Power 10 are:
memcheck/tests/linux/sys-execveat:
more rfcomm.stderr.diff
--- rfcomm.stderr.exp 2021-01-21 10:09:33.000000000 -0500
+++ rfcomm.stderr.out 2024-04-22 11:33:22.949419105 -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 (???:)
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 (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:45)
@@ -18,7 +18,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 (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:45)
@@ -26,7 +26,7 @@
...
by 0x........: main (rfcomm.c:59)
Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:58)
@@ -34,7 +34,7 @@
...
by 0x........: main (rfcomm.c:59)
Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:58)
@@ -42,7 +42,7 @@
...
by 0x........: main (rfcomm.c:63)
Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:58)
@@ -50,7 +50,7 @@
...
by 0x........: main (rfcomm.c:63)
Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:58)
@@ -58,7 +58,7 @@
...
by 0x........: main (rfcomm.c:67)
Address 0x........ is on thread 1's stack
- in frame #1, created by main (rfcomm.c:26)
+ in frame #0, created by bind (???:)
Uninitialised value was created by a client request
at 0x........: main (rfcomm.c:58)
----------------------------------------------------------------------
helgrind/tests/getaddrinfo:
more getaddrinfo.stderr.diff
--- getaddrinfo.stderr.exp 2023-05-16 07:21:42.000000000 -0400
+++ getaddrinfo.stderr.out 2024-04-22 11:36:08.969379829 -0400
@@ -0,0 +1,31 @@
+---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 the Text segment of /usr/lib64/libnss_resolve.so.2
+ ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+ ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+ ...
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+ ...
+ Address 0x........ is in the Text segment of /usr/lib64/libnss_resolve.so.2
+ ...
+
-------------------------------------------------------------------------
drd/tests/std_thread2:
more std_thread2.stderr.diff
--- std_thread2.stderr.exp 2021-01-21 10:09:33.000000000 -0500
+++ std_thread2.stderr.out 2024-04-22 11:39:24.519333567 -0400
@@ -1,9 +1,14 @@
Thread 2:
+Conflicting load by thread 2 at 0x........ size 8
+ at 0x........: _dl_new_hash (dl-new-hash.h:90)
+ by 0x........: _dl_lookup_symbol_x (dl-lookup.c:757)
+Allocation context: Data section of /usr/lib64/ld64.so.2
+
Conflicting store by thread 2 at 0x........ size 4
at 0x........: main::LAMBDA::operator()() const (std_thread2.cpp:21)
Allocation context: BSS section of std_thread2
Done.
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0)
------------------------------------------------------------------
none/tests/socket_close:
more socket_close.stderr.diff
--- socket_close.stderr.exp 2024-04-18 09:59:55.000000000 -0400
+++ socket_close.stderr.out 2024-04-22 11:41:09.189308805 -0400
@@ -10,4 +10,4 @@
Originally opened
at 0x........: socket (in /...libc...)
by 0x........: open_socket (socket_close.c:17)
- by 0x........: main (socket_close.c:31)
+ by 0x........: (below main)
-------------------------------------------------------------------
Carl
Wielaard wrote:
> An RC1 tarball for 3.23.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2
> (md5sum = 6d36fd8981d6aab7350f12cc61973be5)
> (sha1sum = 6ff57d5981d774e446853e8b166be8a3bb324601)
> https://sourceware.org/pub/valgrind/valgrind-3.23.0.RC1.tar.bz2.asc
>
> Please give it a try in configurations that are important for you and
> report any problems you have, either on this mailing list, or
> (preferably) via our bug tracker at
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
>
> RC2 will appear next week, Wednesday 24 April. And if nothing critical
> emerges after that, a final release will happen on Friday 26 April.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
