|
From: Julian S. <js...@ac...> - 2015-09-07 13:44:54
|
Hi, I plan to branch for 3.11.0 in the next 24 hours or so. Please yell ASAP if you believe there to be big breakage on the trunk that should be fixed before that. If the branch seems stable then I propose to let the branch stabilise until Mon 21 Sept and release at that point. J |
|
From: Rhys K. <rhy...@gm...> - 2015-09-10 08:36:16
|
On 7 September 2015 at 21:44, Julian Seward <js...@ac...> wrote: > > Hi, > > I plan to branch for 3.11.0 in the next 24 hours or so. Please > yell ASAP if you believe there to be big breakage on the trunk > that should be fixed before that. > > If the branch seems stable then I propose to let the branch stabilise > until Mon 21 Sept and release at that point. > > J > > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers It appears OS X 10.11, which Valgrind will have preliminary support for from day one, is to be released shortly afterwards on 30 September. Valgrind presently works with the most recent pre-release Developer Beta 8. Regards, Rhys |
|
From: Julian S. <js...@ac...> - 2015-09-10 18:20:47
|
On 07/09/15 15:44, Julian Seward wrote: > If the branch seems stable then I propose to let the branch stabilise > until Mon 21 Sept and release at that point. A test tarball is available at http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) Please test it on systems that are important for you and report any failures (and successes!). I've tested it, to varying extents, on: amd64-linux, Fedora 21 and 22 ppc64-linux (big endian) arm32-linux arm64-linux OSX 10.10 (32 and 64 bit) mips64-linux J |
|
From: Ivo R. <ivo...@gm...> - 2015-09-10 19:45:00
|
2015-09-10 20:20 GMT+02:00 Julian Seward <js...@ac...>: > > On 07/09/15 15:44, Julian Seward wrote: > > If the branch seems stable then I propose to let the branch stabilise > > until Mon 21 Sept and release at that point. > > A test tarball is available at > http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 > (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) > > Please test it on systems that are important for you and report any > failures > (and successes!). > > I've tested it, to varying extents, on: > > amd64-linux, Fedora 21 and 22 > ppc64-linux (big endian) > arm32-linux > arm64-linux > OSX 10.10 (32 and 64 bit) > mips64-linux > Solaris 11.2, 11.3 and 12 are also fine (on x86/amd64 architectures). I. |
|
From: Florian K. <fl...@ei...> - 2015-09-10 21:55:48
|
On 10.09.2015 20:20, Julian Seward wrote: > > On 07/09/15 15:44, Julian Seward wrote: >> If the branch seems stable then I propose to let the branch stabilise >> until Mon 21 Sept and release at that point. > > A test tarball is available at > http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 > (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) > > Please test it on systems that are important for you and report any failures > (and successes!). > s390 Fedora 21 is fine s390 RHEL 4 looks OK to me as well. There are several regtest failures in drd due to a missing filename in the stacktrace. But I'm not going to bother with that. I tested compilation (i.e. "make") with clang on x86-64. You need at least clang-3.1. There are a few warnings about -nodefaultlibs and -u _start but not too many. clang-3.0 will not recognise .cfi_restore This can possibly be worked around by using the GNU assembler instead of clang's built-in assembler. But I did not attempt that. To do "make check" you need 3.4.2 or so. But it's kinda pointless because getting make regtest run somewhat cleanly has not seriously been attempted yet. E.g. with clang-3.7 there are == 722 tests, 183 stderr failures, 59 stdout failures, 1 stderrB failure, 2 stdoutB failures, 4 post failures == Florian |
|
From: Philippe W. <phi...@sk...> - 2015-09-10 22:13:53
|
On Thu, 2015-09-10 at 20:20 +0200, Julian Seward wrote: > On 07/09/15 15:44, Julian Seward wrote: > > If the branch seems stable then I propose to let the branch stabilise > > until Mon 21 Sept and release at that point. > > A test tarball is available at > http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 > (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) > > Please test it on systems that are important for you and report any failures > (and successes!). Working ok on x86/debian8 Philippe |
|
From: Rich C. <rc...@wi...> - 2015-09-11 14:04:16
|
On Thu, 10 Sep 2015 20:20:39 +0200 Julian Seward <js...@ac...> wrote: > > On 07/09/15 15:44, Julian Seward wrote: > > If the branch seems stable then I propose to let the branch stabilise > > until Mon 21 Sept and release at that point. > > A test tarball is available at > http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 > (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) > > Please test it on systems that are important for you and report any failures > (and successes!). > Passed on opensuse 13.2 x86-64 -- Rich Coe rc...@wi... |
|
From: Mark W. <mj...@re...> - 2015-09-11 15:13:29
|
On Thu, 2015-09-10 at 20:20 +0200, Julian Seward wrote: > On 07/09/15 15:44, Julian Seward wrote: > > If the branch seems stable then I propose to let the branch stabilise > > until Mon 21 Sept and release at that point. > > A test tarball is available at > http://valgrind.org/downloads/valgrind-3.11.0.TEST1.tar.bz2 > (md5 = 6a858b4a1e98db8c82bc6bc9c760873b) > > Please test it on systems that are important for you and report any failures > (and successes!). In general it looks pretty good on various systems/arches. I didn't investigate all failures, just some quick comments where I think I know why we don't have zero-fail yet. Please ask if someone wants/needs more info about a specific failure and I can try to get a machine to investigate a little more (all tests were run on remote build machines). amd64, kernel-2.6.18, glibc-2.5, gcc-4.1.2, gdb-7.0.1, binutils-2.17.50.0.6 == 697 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pcmpistri (stderr) memcheck/tests/varinfo5 (stderr) none/tests/amd64-linux/map_32bits (stderr) [The first two seem bad lineinfo from gcc, the mmap just fails] ppc, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 == 587 tests, 7 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 1 post failure == memcheck/tests/leak-segv-jmp (stderr) memcheck/tests/linux/stack_changes (stderr) memcheck/tests/vbit-test/vbit-test (stderr) massif/tests/big-alloc (post) none/tests/libvexmultiarch_test (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) amd64, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 == 716 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_barrier3 (stderr) s390x, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 == 676 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/memcmptest (stderr) [Looks like an exp issue, or maybe inlined code, there is an extra Conditional jump or move depends on uninitialised value(s) in bcmp (vg_replace_strmem.c). The error seems expected, but not exactly at the place where it occurs and/or the extra report.] x86, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 == 646 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == [perfect score!] ppc64, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 == No results == [vgdb tests hang. I doubt it is a valgrind issue, I'll try rerunning without the gdb_server tests.] x86, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1 == 656 tests, 10 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcmain_pic (stderr) memcheck/tests/leak_cpp_interior (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc12_rwl_trivial (stderr) drd/tests/tc18_semabuse (stderr) https://kojipkgs.fedoraproject.org/work/tasks/8116/11038116/build.log amd64, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1 == 725 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcmain_pic (stderr) memcheck/tests/leak_cpp_interior (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc18_semabuse (stderr) https://kojipkgs.fedoraproject.org/work/tasks/8115/11038115/build.log [Now the various tc18/20 tests fail because glibc helpfully puts "The futex facility returned an unexpected error code." on stderr before aborting... Will supply some filter for that.] arm, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1 == 556 tests, 66 stderr failures, 3 stdout failures, 0 stderrB failures, 0 stdoutB failures, 2 post failures == memcheck/tests/dw4 (stderr) memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-segv-jmp (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/stack_changes (stderr) memcheck/tests/lks (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/threadname (stderr) memcheck/tests/threadname_xml (stderr) memcheck/tests/varinfo1 (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) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/arm/v6intARM (stdout) none/tests/arm/v6intThumb (stdout) none/tests/arm/vfp (stdout) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/free_is_write (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/pth_destroy_cond (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/stackteardown (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/annotate_barrier (stderr) drd/tests/annotate_barrier_xml (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) drd/tests/atomic_var (stderr) drd/tests/hg03_inherit (stderr) drd/tests/hg04_race (stderr) drd/tests/hg05_race2 (stderr) drd/tests/rwlock_race (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc18_semabuse (stderr) drd/tests/tc19_shadowmem (stderr) drd/tests/tc21_pthonce (stderr) https://kojipkgs.fedoraproject.org/work/tasks/8114/11038114/build.log [Majority of failures seem to come from bad or missing backtraces.] s390x, kernel-3.19.8, glibc-2.22-2, gcc-5.1.1, gdb-7.10, binutils-2.25 == 685 tests, 8 stderr failures, 0 stdout failures, 14 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/memcmptest (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc18_semabuse (stderr) http://s390.koji.fedoraproject.org/kojifiles/work/tasks/8229/1948229/build.log [The various gdbserver_tests failures are because this version of gdb helpfully outputs things like: warning: Unable to open "librpm.so.3" (librpm.so.3: cannot open shared object file: No such file or directory), missing debuginfos notifications will not be displayed Missing separate debuginfo for /lib/ld64.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6a/... I'll provide some new filters.] ppc64, kernel-3.15.10, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25 == 588 tests, 10 stderr failures, 0 stdout failures, 14 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderr) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc18_semabuse (stderr) http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/3193/2743193/build.log [Same gdb issue as with s390x] ppc64le, kernel-3.15.10, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25 == 587 tests, 8 stderr failures, 0 stdout failures, 14 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc18_semabuse (stderr) http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/3194/2743194/build.log [Likewise.] arm64 kernel-4.1.5, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25 == 579 tests, 30 stderr failures, 7 stdout failures, 14 stderrB failures, 1 stdoutB failure, 2 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/dw4 (stderr) memcheck/tests/leak-segv-jmp (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo1 (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) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/arm64/memory (stdout) none/tests/libvex_test (stderr) none/tests/libvexmultiarch_test (stderr) none/tests/pth_cancel1 (stdout) none/tests/pth_cancel1 (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/pth_cancel_locked (stderr) drd/tests/std_thread (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc18_semabuse (stderr) exp-sgcheck/tests/bad_percentify (stdout) exp-sgcheck/tests/bad_percentify (stderr) exp-sgcheck/tests/globalerr (stderr) exp-sgcheck/tests/hackedbz2 (stdout) exp-sgcheck/tests/hackedbz2 (stderr) exp-sgcheck/tests/hsg (stdout) exp-sgcheck/tests/hsg (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) exp-sgcheck/tests/stackerr (stderr) http://arm.koji.fedoraproject.org//work/tasks/6770/3176770/build.log [Same gdb issue. And various issues caused by output diffs like: - Location 0x........ is 0 bytes inside local var "local" - declared at varinfo1.c:46, in frame #1 of thread 1 + Address 0x........ is on thread 1's stack + in frame #1, created by main (varinfo1.c:45)] |
|
From: Mark W. <mj...@re...> - 2015-09-11 19:05:12
|
And some more results on slightly different setups. Again nothing too worrying, just need to double check the glibc and gdb issues: ppc, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 599 tests, 8 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 1 post failure == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) memcheck/tests/leak-segv-jmp (stderr) memcheck/tests/linux/stack_changes (stderr) memcheck/tests/test-plo-no (stderr) massif/tests/big-alloc (post) none/tests/libvexmultiarch_test (stderr) none/tests/rlimit64_nofile (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) [Some failures because syscall 249 and 325 aren't implemented.] amd64, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 734 tests, 0 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) [hgtls seems to be a gdb bug just fixed by Philippe.] ppc64le, kernel-3.10.0, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 594 tests, 2 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) memcheck/tests/bug340392 (stderr) helgrind/tests/tc06_two_races_xml (stderr) [apparently --expensive-definedness-checks=yes doesn't work for ppc64le?] arm64, kernel-4.2.0, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 579 tests, 35 stderr failures, 6 stdout failures, 13 stderrB failures, 16 stdoutB failures, 0 post failures == gdbserver_tests/hginfo (stderr) gdbserver_tests/hginfo (stdoutB) gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stdoutB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderr) gdbserver_tests/mcclean_after_fork (stdoutB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallRU (stderr) gdbserver_tests/mcinfcallWSRU (stderr) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderr) gdbserver_tests/mcleak (stdoutB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stdout) gdbserver_tests/mcmain_pic (stdoutB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcsignopass (stderr) gdbserver_tests/mcsignopass (stdoutB) gdbserver_tests/mcsigpass (stdoutB) gdbserver_tests/mcvabits (stdoutB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mcwatchpoints (stdoutB) gdbserver_tests/mssnapshot (stdoutB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderr) gdbserver_tests/nlgone_abrt (stdoutB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderr) gdbserver_tests/nlgone_exit (stdoutB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderr) gdbserver_tests/nlgone_return (stdoutB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stdoutB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlvgdbsigqueue (stderr) gdbserver_tests/nlvgdbsigqueue (stdoutB) memcheck/tests/dw4 (stderr) memcheck/tests/leak-segv-jmp (stderr) memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo1 (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) none/tests/libvex_test (stderr) none/tests/libvexmultiarch_test (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/pth_cancel_locked (stderr) drd/tests/std_thread2 (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) exp-sgcheck/tests/bad_percentify (stdout) exp-sgcheck/tests/bad_percentify (stderr) exp-sgcheck/tests/globalerr (stderr) exp-sgcheck/tests/hackedbz2 (stdout) exp-sgcheck/tests/hackedbz2 (stderr) exp-sgcheck/tests/hsg (stdout) exp-sgcheck/tests/hsg (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) exp-sgcheck/tests/stackerr (stderr) [There seem to be a few problems with the gdb on this system. Various issues are because of unexpected output like: - 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) Ignoring those two issues, the results are actually pretty nice.] ppc64, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 620 tests, 38 stderr failures, 34 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/ppc32/power_ISA2_05 (stdout) memcheck/tests/ppc32/power_ISA2_05 (stderr) none/tests/allexec32 (stdout) none/tests/allexec32 (stderr) none/tests/allexec64 (stdout) none/tests/allexec64 (stderr) none/tests/ppc32/bug129390-ppc32 (stdout) none/tests/ppc32/bug129390-ppc32 (stderr) none/tests/ppc32/bug139050-ppc32 (stdout) none/tests/ppc32/bug139050-ppc32 (stderr) none/tests/ppc32/data-cache-instructions (stdout) none/tests/ppc32/data-cache-instructions (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/jm-int (stderr) none/tests/ppc32/jm-misc (stdout) none/tests/ppc32/jm-misc (stderr) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/jm-vmx (stderr) none/tests/ppc32/ldst_multiple (stdout) none/tests/ppc32/ldst_multiple (stderr) none/tests/ppc32/ldstrev (stdout) none/tests/ppc32/ldstrev (stderr) none/tests/ppc32/lsw (stdout) none/tests/ppc32/lsw (stderr) none/tests/ppc32/mcrfs (stdout) none/tests/ppc32/mcrfs (stderr) none/tests/ppc32/mftocrf (stdout) none/tests/ppc32/mftocrf (stderr) none/tests/ppc32/power5+_round (stdout) none/tests/ppc32/power5+_round (stderr) none/tests/ppc32/power6_bcmp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_dfp1 (stdout) none/tests/ppc32/test_dfp1 (stderr) none/tests/ppc32/test_dfp2 (stdout) none/tests/ppc32/test_dfp2 (stderr) none/tests/ppc32/test_dfp3 (stdout) none/tests/ppc32/test_dfp3 (stderr) none/tests/ppc32/test_dfp4 (stdout) none/tests/ppc32/test_dfp4 (stderr) none/tests/ppc32/test_dfp5 (stdout) none/tests/ppc32/test_dfp5 (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) none/tests/ppc32/test_gx (stderr) none/tests/ppc32/test_isa_2_06_part1 (stdout) none/tests/ppc32/test_isa_2_06_part1 (stderr) none/tests/ppc32/test_isa_2_06_part2 (stdout) none/tests/ppc32/test_isa_2_06_part2 (stderr) none/tests/ppc32/test_isa_2_06_part3 (stdout) none/tests/ppc32/test_isa_2_06_part3 (stderr) none/tests/ppc32/testVMX (stdout) none/tests/ppc32/testVMX (stderr) none/tests/ppc32/tw (stdout) none/tests/ppc32/tw (stderr) none/tests/ppc32/twi (stdout) none/tests/ppc32/twi (stderr) none/tests/ppc32/xlc_dbl_u32 (stdout) none/tests/ppc32/xlc_dbl_u32 (stderr) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-fp (stderr) none/tests/ppc64/jm-int (stdout) none/tests/ppc64/jm-int (stderr) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/jm-vmx (stderr) helgrind/tests/tc06_two_races_xml (stderr) [The large number of ppc32 failures seem to come from the usage of a 64bit only instruction in the 32bit ld.so index function.] x86, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 655 tests, 0 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) s390x, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1, gdb-7.6.1 == 684 tests, 4 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/hgtls (stdoutB) memcheck/tests/memcmptest (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/process_vm_readv_writev (stderr) |
|
From: Mark W. <mj...@re...> - 2015-09-12 14:37:34
|
On Fri, 2015-09-11 at 21:05 +0200, Mark Wielaard wrote:
> ppc64, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1,
> gdb-7.6.1
> == 620 tests, 38 stderr failures, 34 stdout failures, 1 stderrB
> failure, 1 stdoutB failure, 0 post failures ==
> gdbserver_tests/hginfo (stderrB)
> gdbserver_tests/hgtls (stdoutB)
> memcheck/tests/bug340392 (stderr)
> memcheck/tests/leak_cpp_interior (stderr)
> memcheck/tests/ppc32/power_ISA2_05 (stdout)
> memcheck/tests/ppc32/power_ISA2_05 (stderr)
> none/tests/allexec32 (stdout)
> none/tests/allexec32 (stderr)
> none/tests/allexec64 (stdout)
> none/tests/allexec64 (stderr)
> none/tests/ppc32/bug129390-ppc32 (stdout)
> none/tests/ppc32/bug129390-ppc32 (stderr)
> none/tests/ppc32/bug139050-ppc32 (stdout)
> none/tests/ppc32/bug139050-ppc32 (stderr)
> none/tests/ppc32/data-cache-instructions (stdout)
> none/tests/ppc32/data-cache-instructions (stderr)
> none/tests/ppc32/jm-fp (stdout)
> none/tests/ppc32/jm-fp (stderr)
> none/tests/ppc32/jm-int (stdout)
> none/tests/ppc32/jm-int (stderr)
> none/tests/ppc32/jm-misc (stdout)
> none/tests/ppc32/jm-misc (stderr)
> none/tests/ppc32/jm-vmx (stdout)
> none/tests/ppc32/jm-vmx (stderr)
> none/tests/ppc32/ldst_multiple (stdout)
> none/tests/ppc32/ldst_multiple (stderr)
> none/tests/ppc32/ldstrev (stdout)
> none/tests/ppc32/ldstrev (stderr)
> none/tests/ppc32/lsw (stdout)
> none/tests/ppc32/lsw (stderr)
> none/tests/ppc32/mcrfs (stdout)
> none/tests/ppc32/mcrfs (stderr)
> none/tests/ppc32/mftocrf (stdout)
> none/tests/ppc32/mftocrf (stderr)
> none/tests/ppc32/power5+_round (stdout)
> none/tests/ppc32/power5+_round (stderr)
> none/tests/ppc32/power6_bcmp (stderr)
> none/tests/ppc32/round (stdout)
> none/tests/ppc32/round (stderr)
> none/tests/ppc32/test_dfp1 (stdout)
> none/tests/ppc32/test_dfp1 (stderr)
> none/tests/ppc32/test_dfp2 (stdout)
> none/tests/ppc32/test_dfp2 (stderr)
> none/tests/ppc32/test_dfp3 (stdout)
> none/tests/ppc32/test_dfp3 (stderr)
> none/tests/ppc32/test_dfp4 (stdout)
> none/tests/ppc32/test_dfp4 (stderr)
> none/tests/ppc32/test_dfp5 (stdout)
> none/tests/ppc32/test_dfp5 (stderr)
> none/tests/ppc32/test_fx (stdout)
> none/tests/ppc32/test_fx (stderr)
> none/tests/ppc32/test_gx (stdout)
> none/tests/ppc32/test_gx (stderr)
> none/tests/ppc32/test_isa_2_06_part1 (stdout)
> none/tests/ppc32/test_isa_2_06_part1 (stderr)
> none/tests/ppc32/test_isa_2_06_part2 (stdout)
> none/tests/ppc32/test_isa_2_06_part2 (stderr)
> none/tests/ppc32/test_isa_2_06_part3 (stdout)
> none/tests/ppc32/test_isa_2_06_part3 (stderr)
> none/tests/ppc32/testVMX (stdout)
> none/tests/ppc32/testVMX (stderr)
> none/tests/ppc32/tw (stdout)
> none/tests/ppc32/tw (stderr)
> none/tests/ppc32/twi (stdout)
> none/tests/ppc32/twi (stderr)
> none/tests/ppc32/xlc_dbl_u32 (stdout)
> none/tests/ppc32/xlc_dbl_u32 (stderr)
> none/tests/ppc64/jm-fp (stdout)
> none/tests/ppc64/jm-fp (stderr)
> none/tests/ppc64/jm-int (stdout)
> none/tests/ppc64/jm-int (stderr)
> none/tests/ppc64/jm-vmx (stdout)
> none/tests/ppc64/jm-vmx (stderr)
> helgrind/tests/tc06_two_races_xml (stderr)
>
> [The large number of ppc32 failures seem to come from the usage of
> a 64bit only instruction in the 32bit ld.so index function.]
I tried with a slightly newer glibc version and couldn't replicate the
ppc32 failures. The results now look like:
== 634 tests, 6 stderr failures, 3 stdout failures, 0 stderrB failures,
1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
none/tests/ppc64/jm-fp (stdout)
none/tests/ppc64/jm-fp (stderr)
none/tests/ppc64/jm-int (stdout)
none/tests/ppc64/jm-int (stderr)
none/tests/ppc64/jm-vmx (stdout)
none/tests/ppc64/jm-vmx (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
The jm-fp, jm-int and jm-vmx tests all fail because they crash (also
when running natively) inside this code:
Program received signal SIGSEGV, Segmentation fault.
init_function (func_buf=0x3fffb7d70000,
p_func_F=@0x1001e328: 0x10000bd4 <.test_lfs>) at jm-insns.c:4875
4875 descr[0] = (uint64_t)&func_buf[0];
4868 /* p_func points to a function descriptor, the first word of which
4869 points to the real code. Copy the code itself but not the
4870 descriptor, and just swizzle the descriptor's entry pointer. */
4871 uint64_t* descr = (uint64_t*)p_func;
4872 uint32_t* entry = (uint32_t*)(descr[0]);
4873 func_buf[0] = entry[0];
4874 func_buf[1] = entry[1];
4875 descr[0] = (uint64_t)&func_buf[0];
4876 return (test_func_t)descr;
4877 #endif // #ifndef __powerpc64__
|
|
From: Florian K. <fl...@ei...> - 2015-09-12 08:07:14
|
On 11.09.2015 17:06, Mark Wielaard wrote:
>
> ppc, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2
> == 587 tests, 7 stderr failures, 0 stdout failures, 0 stderrB failures,
> 0 stdoutB failures, 1 post failure ==
> memcheck/tests/leak-segv-jmp (stderr)
> memcheck/tests/linux/stack_changes (stderr)
> memcheck/tests/vbit-test/vbit-test (stderr)
I'd be interested in the vbit-test failure. This should not happen.
Florian
|
|
From: Mark W. <mj...@re...> - 2015-09-12 13:53:46
|
On Fri, 2015-09-11 at 17:06 +0200, Mark Wielaard wrote: > ppc64, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, > binutils-2.20.51.0.2 > == No results == > > [vgdb tests hang. I doubt it is a valgrind issue, I'll try rerunning > without the gdb_server tests.] I tried to replicate this and failed to reproduce the hang. The result is actually near perfect for this setup: == 614 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/bug340392 (stderr) So that means it is just that --expensive-definedness-checks=yes doesn't help on ppc64 for this testcase. |
|
From: Florian K. <fl...@ei...> - 2015-09-12 19:26:03
|
On 12.09.2015 15:53, Mark Wielaard wrote: > == 614 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == > memcheck/tests/bug340392 (stderr) > > So that means it is just that --expensive-definedness-checks=yes doesn't > help on ppc64 for this testcase. > Known issue: https://bugs.kde.org/show_bug.cgi?id=352364 Florian |
|
From: Mark W. <mj...@re...> - 2015-09-12 15:23:50
|
On Sat, 2015-09-12 at 10:06 +0200, Florian Krohm wrote: > On 11.09.2015 17:06, Mark Wielaard wrote: > > > > ppc, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 > > == 587 tests, 7 stderr failures, 0 stdout failures, 0 stderrB failures, > > 0 stdoutB failures, 1 post failure == > > memcheck/tests/leak-segv-jmp (stderr) > > memcheck/tests/linux/stack_changes (stderr) > > memcheck/tests/vbit-test/vbit-test (stderr) > > I'd be interested in the vbit-test failure. This should not happen. Sadly I don't have interactive access to the machine that produces this result and I cannot replicate on a (different) ppc64 setup. Even when running everything under "setarch ppc32" the vbit test passes just fine. All I can offer you at the moment is the unfiltered output: :::::::::::::: memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out :::::::::::::: ==8767== ==8767== Process terminating with default action of signal 4 (SIGILL) ==8767== Illegal opcode at address 0x834D26BC ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) ==8767== by 0x10001D27: test_binary_op (binary.c:461) ==8767== by 0x10000BCB: main (main.c:135) So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. |
|
From: Florian K. <fl...@ei...> - 2015-09-12 18:42:57
|
On 12.09.2015 17:23, Mark Wielaard wrote: > All I can offer you at the moment is the unfiltered output: > > :::::::::::::: > memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out > :::::::::::::: > ==8767== > ==8767== Process terminating with default action of signal 4 (SIGILL) > ==8767== Illegal opcode at address 0x834D26BC > ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) > ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) > ==8767== by 0x10001D27: test_binary_op (binary.c:461) > ==8767== by 0x10000BCB: main (main.c:135) > > So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. > That would suggest that the injected code is invalid for ppc32. Can you rerun with: Index: memcheck/tests/vbit-test/vbit-test.vgtest =================================================================== --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) @@ -1,2 +1,3 @@ prog: vbit-test vgopts: -q +args: -v -v The .out file should tell which IROp is causing it. Florian |
|
From: Florian K. <fl...@ei...> - 2015-09-12 19:37:28
|
On 11.09.2015 17:06, Mark Wielaard wrote:
> arm, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1
> arm64 kernel-4.1.5, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25
Ah, nice.. gcc-5.1.1.. so we can flush out format signedness issues on
arm*
When you get a chance, can you rerun (just make) with:
Index: configure.ac
===================================================================
--- configure.ac (revision 15648)
+++ configure.ac (working copy)
@@ -1913,7 +1913,7 @@
AC_GCC_WARNING_SUBST([format], [FLAG_W_FORMAT])
# Disabled for now until all platforms are clean
format_checking_enabled=no
-#format_checking_enabled=yes
+format_checking_enabled=yes
if test "$format_checking_enabled" = "yes"; then
AC_GCC_WARNING_SUBST([format-signedness], [FLAG_W_FORMAT_SIGNEDNESS])
else
and send me the warnings?
Thanks,
Florian
|
|
From: Mark W. <mj...@re...> - 2015-09-12 20:10:17
|
On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: > On 12.09.2015 17:23, Mark Wielaard wrote: > > > All I can offer you at the moment is the unfiltered output: > > > > :::::::::::::: > > memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out > > :::::::::::::: > > ==8767== > > ==8767== Process terminating with default action of signal 4 (SIGILL) > > ==8767== Illegal opcode at address 0x834D26BC > > ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) > > ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) > > ==8767== by 0x10001D27: test_binary_op (binary.c:461) > > ==8767== by 0x10000BCB: main (main.c:135) > > > > So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. > > > > That would suggest that the injected code is invalid for ppc32. > Can you rerun with: > > Index: memcheck/tests/vbit-test/vbit-test.vgtest > =================================================================== > --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) > +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) > @@ -1,2 +1,3 @@ > prog: vbit-test > vgopts: -q > +args: -v -v > > The .out file should tell which IROp is causing it. :::::::::::::: memcheck/tests/vbit-test/vbit-test.stdout.out :::::::::::::: Testing operator Iop_Add8 Testing operator Iop_Add16 Testing operator Iop_Add32 Testing operator Iop_Add64 Testing operator Iop_Sub8 Testing operator Iop_Sub32 Testing operator Iop_Mul32 Testing operator Iop_Or8 Testing operator Iop_Or16 Testing operator Iop_Or32 Testing operator Iop_Or64 Testing operator Iop_And8 Testing operator Iop_And16 Testing operator Iop_And32 Testing operator Iop_And64 Testing operator Iop_Xor8 Testing operator Iop_Xor16 Testing operator Iop_Xor32 Testing operator Iop_Xor64 Testing operator Iop_Shl8 Testing operator Iop_Shl16 Testing operator Iop_Shl32 Testing operator Iop_Shr32 Testing operator Iop_Sar32 Testing operator Iop_CmpEQ32 Testing operator Iop_CmpNE32 Testing operator Iop_Not8 Testing operator Iop_Not16 Testing operator Iop_Not32 Testing operator Iop_Not64 Testing operator Iop_MullS32 Testing operator Iop_MullU32 Testing operator Iop_Clz32 Testing operator Iop_CmpLT32S Testing operator Iop_CmpLE32S Testing operator Iop_CmpLT32U Testing operator Iop_CmpLE32U Testing operator Iop_CmpwNEZ32 Testing operator Iop_CmpwNEZ64 Testing operator Iop_CmpORD32U Testing operator Iop_CmpORD32S Testing operator Iop_DivU32 Testing operator Iop_DivS32 Testing operator Iop_DivU32E |
|
From: Florian K. <fl...@ei...> - 2015-09-12 20:46:48
|
On 12.09.2015 22:10, Mark Wielaard wrote: > On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: >> On 12.09.2015 17:23, Mark Wielaard wrote: >> >>> All I can offer you at the moment is the unfiltered output: >>> >>> :::::::::::::: >>> memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out >>> :::::::::::::: >>> ==8767== >>> ==8767== Process terminating with default action of signal 4 (SIGILL) >>> ==8767== Illegal opcode at address 0x834D26BC >>> ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) >>> ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) >>> ==8767== by 0x10001D27: test_binary_op (binary.c:461) >>> ==8767== by 0x10000BCB: main (main.c:135) >>> >>> So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. >>> >> >> That would suggest that the injected code is invalid for ppc32. >> Can you rerun with: >> >> Index: memcheck/tests/vbit-test/vbit-test.vgtest >> =================================================================== >> --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) >> +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) >> @@ -1,2 +1,3 @@ >> prog: vbit-test >> vgopts: -q >> +args: -v -v >> >> The .out file should tell which IROp is causing it. > > :::::::::::::: > memcheck/tests/vbit-test/vbit-test.stdout.out > :::::::::::::: .... > Testing operator Iop_DivU32E > Ah yes.. In host_ppc_isel.c around line 1538 a PPCInstr_Div with extended == 1 is created for tat IROp. Then in host_ppc_defs.c around line 4082 a divweu is generated for that. That seems to be an insn that is only available for power7 and newer. I do not know that for sure but http://www-01.ibm.com/support/knowledgecenter/SSGH4D_14.1.0/com.ibm.xlf141.aix.doc/language_ref/divwe.html says so for divwe (which is for signed extended division). I'd say, this is a bug in the powerpc port. Carl, what do you think? Florian |
|
From: Mark W. <mj...@re...> - 2015-09-13 13:08:11
Attachments:
arm.warning.log.bz2
|
On Sat, 2015-09-12 at 21:37 +0200, Florian Krohm wrote:
> On 11.09.2015 17:06, Mark Wielaard wrote:
>
> > arm, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1
>
> > arm64 kernel-4.1.5, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25
>
> Ah, nice.. gcc-5.1.1.. so we can flush out format signedness issues on
> arm*
> When you get a chance, can you rerun (just make) with:
> [...]
> +format_checking_enabled=yes
> [...]
> and send me the warnings?
arm64 didn't show any -Wformat -Wformat-signedness -Wformat-security
warnings (nor any other warnings).
arm had one format warning:
m_debuginfo/readexidx.c: In function ‘vgModuleLocal_read_exidx’:
m_debuginfo/readexidx.c:941:19: warning: format ‘%lx’ expects argument
of type ‘long unsigned int’, but argument 7 has type ‘PtrdiffT {aka long
int}’ [-Wformat=]
VG_(printf)("BEGIN ML_(read_exidx) exidx_img=[%p, +%lu) "
^
There was also one -Wunused-but-set-variable warning:
m_sigframe/sigframe-arm-linux.c: In function ‘vgPlain_sigframe_destroy’:
m_sigframe/sigframe-arm-linux.c:251:27: warning: variable ‘mc’ set but
not used [-Wunused-but-set-variable]
struct vki_sigcontext *mc;
^
And lots of -Wcast-qual and -Wcast-align warnings (see attached).
Cheers,
Mark
|
|
From: Florian K. <fl...@ei...> - 2015-09-13 20:31:26
|
On 13.09.2015 15:08, Mark Wielaard wrote:
>
> arm had one format warning:
>
> m_debuginfo/readexidx.c: In function ‘vgModuleLocal_read_exidx’:
> m_debuginfo/readexidx.c:941:19: warning: format ‘%lx’ expects argument
> of type ‘long unsigned int’, but argument 7 has type ‘PtrdiffT {aka long
> int}’ [-Wformat=]
> VG_(printf)("BEGIN ML_(read_exidx) exidx_img=[%p, +%lu) "
> ^
>
> There was also one -Wunused-but-set-variable warning:
>
> m_sigframe/sigframe-arm-linux.c: In function ‘vgPlain_sigframe_destroy’:
> m_sigframe/sigframe-arm-linux.c:251:27: warning: variable ‘mc’ set but
> not used [-Wunused-but-set-variable]
> struct vki_sigcontext *mc;
> ^
Thanks for the trial runs.
I fixed those warnings in r15650.]
> And lots of -Wcast-qual and -Wcast-align warnings (see attached).
>
as well as the 3 Wcast-qual warnings. I did not do anything about the
cast-align warnings as that is a warning specific to your compile
environment (stock valgrind does not compile with -Wcast-align).
Florian
|
|
From: Mark W. <mj...@re...> - 2015-09-13 21:04:07
|
Hi Florian, On Sun, Sep 13, 2015 at 10:31:14PM +0200, Florian Krohm wrote: > I fixed those warnings in r15650.] Thanks! > I did not do anything about the > cast-align warnings as that is a warning specific to your compile > environment (stock valgrind does not compile with -Wcast-align). Are you sure? Makefile.all.am adds -Wcast-align to AM_CFLAGS_BASE. Cheers, Mark |
|
From: Mark W. <mj...@re...> - 2015-09-13 21:22:25
|
On Fri, Sep 11, 2015 at 05:06:11PM +0200, Mark Wielaard wrote: > [Now the various tc18/20 tests fail because glibc helpfully puts "The > futex facility returned an unexpected error code." on stderr before > aborting... Will supply some filter for that.] I couldn't replicate this. > [The various gdbserver_tests failures are because this version of gdb > helpfully outputs things like: > warning: Unable to open "librpm.so.3" (librpm.so.3: cannot open shared > object file: No such file or directory), missing debuginfos > notifications will not be displayed > Missing separate debuginfo for /lib/ld64.so.1 > Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6a/... > I'll provide some new filters.] I also couldn't replicate this. I suspect it was caused by some bad gdb dependencies on the build machine. So for now I haven't added any new filters. I might add them later if those extra stderr messages do return and I am able to replicate them. Cheers, Mark |
|
From: Mark W. <mj...@re...> - 2015-09-18 09:17:29
|
On Sun, 2015-09-13 at 23:22 +0200, Mark Wielaard wrote: > On Fri, Sep 11, 2015 at 05:06:11PM +0200, Mark Wielaard wrote: > > [Now the various tc18/20 tests fail because glibc helpfully puts "The > > futex facility returned an unexpected error code." on stderr before > > aborting... Will supply some filter for that.] > > I couldn't replicate this. Replicated that now. Some glibc versions indeed just barf some warning messages when getting unexpected futex syscall results. I have filtered them out for the tests in r15654. |
|
From: Florian K. <fl...@ei...> - 2015-09-14 08:25:25
|
Hi Mark,
>> I did not do anything about the
>> cast-align warnings as that is a warning specific to your compile
>> environment (stock valgrind does not compile with -Wcast-align).
>
> Are you sure?
no :)
> Makefile.all.am adds -Wcast-align to AM_CFLAGS_BASE.
Right you are. I had incorrectly concluded from the absence of any
cast-align warnings on other platforms, that you had somehow added that
option. But as gcc docs point out:
'-Wcast-align'
Warn whenever a pointer is cast such that the required alignment of
the target is increased. For example, warn if a 'char *' is cast
to an 'int *' on machines where integers can only be accessed at
two- or four-byte boundaries.
So the warning is machine dependent.
>From this page
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html
I gather that unaligned access is OK for ARMv6 and newer.
http://valgrind.org/info/platforms.html says we support ARMv7 so we
should be OK and can ignore those warnings. Perhaps your arm build was
on something older ?
Florian
|
|
From: Mark W. <mj...@re...> - 2015-09-14 09:32:30
|
On Mon, 2015-09-14 at 10:25 +0200, Florian Krohm wrote: > '-Wcast-align' > Warn whenever a pointer is cast such that the required alignment of > the target is increased. For example, warn if a 'char *' is cast > to an 'int *' on machines where integers can only be accessed at > two- or four-byte boundaries. > > So the warning is machine dependent. > From this page > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html > I gather that unaligned access is OK for ARMv6 and newer. > http://valgrind.org/info/platforms.html says we support ARMv7 so we > should be OK and can ignore those warnings. Perhaps your arm build was > on something older ? It was an armv7+. But GCC outputs the warning when the backend defines STRICT_ALIGNMENT to 1. Which arm does unconditionally. It does support some unaligned access and there is -munaligned-access (which defaults to 1 when on armv6+). But That seems to be only for some access or some instructions. I think this explains why: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459#c4 Some unaligned accesses might still use instructions that don't support unaligned access and so trap into the kernel to adjust those. Which will slow down stuff a lot. So you still get a warning, just in case... Cheers, Mark |