|
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
|