|
From: Mark W. <ma...@kl...> - 2022-04-02 19:51:14
|
Hi valgrind hackers, An RC1 tarball for 3.19.0 is now available at ftp://sourceware.org/pub/valgrind/valgrind-3.19.0.RC1.tar.bz2 https://sourceware.org/pub/valgrind/valgrind-3.19.0.RC1.tar.bz2 (md5sum = d784310ca4c159e4d6c36c7dacffc3ed) 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 There are are couple of issues I like to look into which have patches that need review: 451878 Add support for new syscall memfd_secret 450437 Warn for execve syscall with argv or argv[0] being NULL. 445011 SIGCHLD is sent when valgrind uses debuginfod-find And this not yet fully understood issue: 452058 Generated suppressions contain a mix of mangled (physical) and demangled (inline) frames If there are any other urgent issues please do propose patches. I'll like to do an RC2 on Wednesday, with a final release on Friday, April 8th if everything goes well. I ran make regtest on a Fedora 36 pre-release on x86_64, s390x, ppc64le and aarch64 which uses: gcc 12.0.1 (pre-release) binutils 2.37 glibc 2.35 kernel 5.17.0.rc7 (pre-release) I assumed we would have more test cases issues with GCC 12 since that showed more warnings and more aggressively inlined some functions, but it seems Paul already fixed all those issues. On all architectures there are two drd failures which are unexplained for now. ppc64le has a couple of failures where the aspace manager crashes with: --492941:0: aspacem segment mismatch: V's seg 1st, kernel's 2nd: --492941:0: aspacem 1: file 0004000000-000400ffff 65536 r---- SmFixed d=0x........ i=8463 o=0 (2,89) /usr/lib64/ld64.so.2 --492941:0: aspacem ...: .... 0004000000-000400ffff 65536 r--.. ....... d=0x........ i=8463 o=0 (.) m=. /usr/lib64/ld64.so.2 --492941:0: aspacem sync check at m_aspacemgr/aspacemgr-linux.c:2142 (vgPlain_am_get_advisory): FAILED --492941:0: aspacem --492941:0: aspacem Valgrind: FATAL: aspacem assertion failed: --492941:0: aspacem VG_(am_do_sync_check) (__PRETTY_FUNCTION__,__FILE__,__LINE__) --492941:0: aspacem at m_aspacemgr/aspacemgr-linux.c:2142 (vgPlain_am_get_advisory) --492941:0: aspacem Exiting now. I think this comes from the new kernel, since it is an rc kernel maybe it is an kernel issue. I'll try to retest with a 5.17.0 final kernel. x86_64 == 727 tests, 4 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/overlap (stderr) helgrind/tests/tls_threads (stderr) drd/tests/pth_mutex_signal (stderr) drd/tests/shared_timed_mutex (stderr) s390x == 773 tests, 4 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/vbit-test/vbit-test (stderr) helgrind/tests/tls_threads (stderr) drd/tests/pth_mutex_signal (stderr) drd/tests/shared_timed_mutex (stderr) ppc64le == 672 tests, 10 stderr failures, 4 stdout failures, 1 stderrB failure, 0 stdoutB failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) helgrind/tests/tls_threads (stderr) drd/tests/pth_barrier_thr_cr (stderr) drd/tests/pth_mutex_signal (stderr) drd/tests/shared_timed_mutex (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/bigcode (stdout) none/tests/bigcode (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) aarch64 == 647 tests, 14 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) memcheck/tests/dw4 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/varinforestrict (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tls_threads (stderr) drd/tests/pth_barrier_thr_cr (stderr) drd/tests/pth_mutex_signal (stderr) drd/tests/shared_timed_mutex (stderr) |
|
From: Carl L. <ce...@us...> - 2022-04-04 16:57:07
|
Mark:
Here is the results of running the Valgrind-3.19.0 RC1 candidate on
various Power systems.
On Sat, 2022-04-02 at 21:51 +0200, Mark Wielaard wrote:
> Hi valgrind hackers,
>
> An RC1 tarball for 3.19.0 is now available at
>
>
<snip>
> On all architectures there are two drd failures which are unexplained
> for now. ppc64le has a couple of failures where the aspace manager
> crashes with:
>
> --492941:0: aspacem segment mismatch: V's seg 1st, kernel's 2nd:
> --492941:0: aspacem 1: file 0004000000-000400ffff 65536 r----
> SmFixed d=0x........ i=8463 o=0 (2,89) /usr/lib64/ld64.so.2
> --492941:0: aspacem ...: .... 0004000000-000400ffff 65536 r--..
> ....... d=0x........ i=8463 o=0 (.) m=. /usr/lib64/ld64.so.2
> --492941:0: aspacem sync check at m_aspacemgr/aspacemgr-linux.c:2142
> (vgPlain_am_get_advisory): FAILED
> --492941:0: aspacem
> --492941:0: aspacem Valgrind: FATAL: aspacem assertion failed:
> --492941:0: aspacem VG_(am_do_sync_check)
> (__PRETTY_FUNCTION__,__FILE__,__LINE__)
> --492941:0: aspacem at m_aspacemgr/aspacemgr-linux.c:2142
> (vgPlain_am_get_advisory)
> --492941:0: aspacem Exiting now.
>
> I think this comes from the new kernel, since it is an rc kernel
> maybe
> it is an kernel issue. I'll try to retest with a 5.17.0 final kernel.
>
<snip>
> ppc64le
> == 672 tests, 10 stderr failures, 4 stdout failures, 1 stderrB
> failure, 0 stdoutB failures, 2 post failures ==
> gdbserver_tests/hginfo (stderrB)
> memcheck/tests/bug340392 (stderr)
> memcheck/tests/linux/rfcomm (stderr)
> helgrind/tests/tls_threads (stderr)
> drd/tests/pth_barrier_thr_cr (stderr)
> drd/tests/pth_mutex_signal (stderr)
> drd/tests/shared_timed_mutex (stderr)
> massif/tests/new-cpp (post)
> massif/tests/overloaded-new (post)
> none/tests/bigcode (stdout)
> none/tests/bigcode (stderr)
> none/tests/map_unmap (stdout)
> none/tests/map_unmap (stderr)
> none/tests/sigstackgrowth (stdout)
> none/tests/sigstackgrowth (stderr)
> none/tests/stackgrowth (stdout)
> none/tests/stackgrowth (stderr)
I ran the RC1 on Power 10LE Ubuntu 21.04, gcc (Ubuntu 11.2.0-7ubuntu2)
with the following results,11.2.0:
== 680 tests, 9 stderr failures, 0 stdout failures, 1 stderrB failure,
1 stdoutB failure, 3 post failures ==
gdbserver_tests/hginfo (stderrB)
gdbserver_tests/mcsignopass (stderr)
gdbserver_tests/mcsigpass (stderr)
gdbserver_tests/nlcontrolc (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-execveat (stderr)
helgrind/tests/tls_threads (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/shared_timed_mutex (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
none/tests/faultstatus (stderr)
I ran the RC1 on Power 10LE RHEL 9 (Pre-release build), gcc (GCC)
11.2.1 20220127 (Red Hat 11.2.1-9) with the following results:
== 679 tests, 5 stderr failures, 0 stdout failures, 3 stderrB failures,
18 stdo\
utB failures, 3 post failures ==
gdbserver_tests/hginfo (stdoutB)
gdbserver_tests/hginfo (stderrB)
gdbserver_tests/hgtls (stdoutB)
gdbserver_tests/mcblocklistsearch (stderrB)
gdbserver_tests/mcbreak (stdoutB)
gdbserver_tests/mcclean_after_fork (stdoutB)
gdbserver_tests/mcinfcallWSRU (stderrB)
gdbserver_tests/mcleak (stdoutB)
gdbserver_tests/mcmain_pic (stdoutB)
gdbserver_tests/mcsignopass (stdoutB)
gdbserver_tests/mcsigpass (stdoutB)
gdbserver_tests/mcvabits (stdoutB)
gdbserver_tests/mcwatchpoints (stdoutB)
gdbserver_tests/mssnapshot (stdoutB)
gdbserver_tests/nlcontrolc (stdoutB)
gdbserver_tests/nlgone_abrt (stdoutB)
gdbserver_tests/nlgone_exit (stdoutB)
gdbserver_tests/nlgone_return (stdoutB)
gdbserver_tests/nlpasssigalrm (stdoutB)
gdbserver_tests/nlsigvgdb (stdoutB)
gdbserver_tests/nlvgdbsigqueue (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
helgrind/tests/tls_threads (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/shared_timed_mutex (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
I am guessing there may be a bit of a mismatch on the gdbserver given
that it is a pre-release. Can't prove that, but I have seen gdbserver
issues in the past when everything is not in sync.
I ran the RC1 on Power 9 LE Ubuntu 20.04, gcc (Ubuntu 9.3.0-
17ubuntu1~20.04) 9.3.0 with the following results:
= 671 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures,
1 stdoutB failure, 3 post failures ==
gdbserver_tests/nlcontrolc (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-execveat (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/shared_timed_mutex (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
I ran the RC1 on Power 8 LE Ubuntu 20.04, gcc (Ubuntu 9.4.0-
1ubuntu1~20.04) 9.4.0 with the following results:
== 667 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures,
1 stdoutB failure, 3 post failures ==
gdbserver_tests/nlcontrolc (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-execveat (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/shared_timed_mutex (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
I ran the RC1 on Power 8 RHEL7.8, gcc (GCC) 4.8.5 20150623 (Red Hat
4.8.5-39) with the following results:
== 708 tests, 5 stderr failures, 1 stdout failure, 0 stderrB failures,
2 stdoutB failures, 1 post failure ==
gdbserver_tests/nlgone_abrt (stdoutB)
gdbserver_tests/nlpasssigalrm (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/std_mutex (stderr)
drd/tests/timed_mutex (stderr)
none/tests/ppc32/jm_vec_isa_2_07 (stdout)
The jm_vec_isa_2_07 failures is due to a couple of the vpermq tests
failing. Looks like I didn't run the regression test for the vpermq
tests on Power 8 BE. I will take a look at these failures today.
Other than that, I don't see anything of concern with regards to
Powerpc for the release.
Carl Love
|
|
From: Carl L. <ce...@us...> - 2022-04-05 01:53:24
|
Mark:
On Mon, 2022-04-04 at 09:56 -0700, Carl Love wrote:
>
<snip>
>
> I ran the RC1 on Power 8 RHEL7.8, gcc (GCC) 4.8.5 20150623 (Red Hat
> 4.8.5-39) with the following results:
>
> == 708 tests, 5 stderr failures, 1 stdout failure, 0 stderrB
> failures,
> 2 stdoutB failures, 1 post failure ==
> gdbserver_tests/nlgone_abrt (stdoutB)
> gdbserver_tests/nlpasssigalrm (stdoutB)
> memcheck/tests/bug340392 (stderr)
> memcheck/tests/leak_cpp_interior (stderr)
> drd/tests/pth_mutex_signal (stderr)
> drd/tests/std_mutex (stderr)
> drd/tests/timed_mutex (stderr)
> none/tests/ppc32/jm_vec_isa_2_07 (stdout)
>
> The jm_vec_isa_2_07 failures is due to a couple of the vpermq tests
> failing. Looks like I didn't run the regression test for the vpermq
> tests on Power 8 BE. I will take a look at these failures today.
I have updated the bugzilla 451827 for the vbpermq re-write with a fix
for the Powerpc 32-bit mode. The fix was retested on all platforms.
No additional regression issues were seen. The Power 8 BE tests now
pass as expected.
== 708 tests, 5 stderr failures, 0 stdout failures, 0 stderrB failures,
2 stdoutB failures, 1 post failure ==
gdbserver_tests/nlgone_abrt (stdoutB)
gdbserver_tests/nlpasssigalrm (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
drd/tests/pth_mutex_signal (stderr)
drd/tests/std_mutex (stderr)
drd/tests/timed_mutex (stderr)
I think we are good to go on Power.
Carl Love
|
|
From: Mark W. <ma...@kl...> - 2022-04-08 10:26:09
|
Hi valgrind hackers, On Sat, 2022-04-02 at 21:51 +0200, Mark Wielaard wrote: > An RC1 tarball for 3.19.0 is now available at > ftp://sourceware.org/pub/valgrind/valgrind-3.19.0.RC1.tar.bz2 > https://sourceware.org/pub/valgrind/valgrind-3.19.0.RC1.tar.bz2 > (md5sum = d784310ca4c159e4d6c36c7dacffc3ed) > > 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 > > There are are couple of issues I like to look into which have patches > that need review: > 451878 Add support for new syscall memfd_secret > 450437 Warn for execve syscall with argv or argv[0] being NULL. > 445011 SIGCHLD is sent when valgrind uses debuginfod-find > > And this not yet fully understood issue: > 452058 Generated suppressions contain a mix of mangled (physical) > and demangled (inline) frames > > If there are any other urgent issues please do propose patches. > > I'll like to do an RC2 on Wednesday, with a final release on Friday, > April 8th if everything goes well. So, I didn't make the RC2 on Wednesday because we are still fixing some bugs (although in general things look pretty good). I'll do an RC2 later today (Friday) and if that looks good after some more testing do the final 3.19.0 release on Monday (April 11). Cheers, Mark |