First observed against a glibc and valgrind compiled with -O2 -march=z10 -mtune=zEC12. That seems to generate s390 code in both the vgpreload libraries and glibc that gets miscompiled by V. Causing address accesses to non-mapped memory. It can be reproduced on both valgrind 3.8.1 and 3.9.0 with generic strncpy like code build with gcc 3.8.1 -O2 -march=z10 (will attach example). Reproducible: Always Steps to Reproduce: 1. gcc -march=z10 -g -Wall -O2 -o mystrncpy mystrncpy.c (That is gcc 4.8.2, when using -march=z9-109 things work fine) 2. valgrind --tool=none ./mystrncpy "/usr/bin:/root/bin" Actual Results: ==34932== Nulgrind, the minimal Valgrind tool ==34932== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==34932== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==34932== Command: ../mystrncpy /usr/bin:/root/bin ==34932== ==34932== ==34932== Process terminating with default action of signal 11 (SIGSEGV) ==34932== Access not within mapped region at address 0x80025000 ==34932== at 0x80000730: mystrncpy_chk (mystrncpy.c:85) ==34932== by 0x8000052F: main (mystrncpy.c:97) ==34932== If you believe this happened as a result of a stack ==34932== overflow in your program's main thread (unlikely but ==34932== possible), you can try to increase the size of the ==34932== main thread stack using the --main-stacksize= flag. ==34932== The main thread stack size used in this run was 8388608. ==34932== Segmentation fault Expected Results: As seen when using gcc -march=z9-109 -g -Wall -O2 -o mystrncpy mystrncpy.c ==34941== Nulgrind, the minimal Valgrind tool ==34941== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==34941== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==34941== Command: ../mystrncpy /usr/bin:/root/bin ==34941== 19, /usr/bin ==34941== This was originally https://bugzilla.redhat.com/show_bug.cgi?id=1018325 valgrind memcheck segfaults on s390x
Created attachment 83408 [details] mystrncpy.c reproducer when build with -march=z10 -O2 on gcc 4.8.2 This is based on is based on the strncpy_chk.c code from glibc code. gcc -march=z10 -g -Wall -O2 -o mystrncpy mystrncpy.c valgrind --tool=none ./mystrncpy "/usr/bin:/root/bin" valgrind --tool=none ./mystrncpy "/usr/bin:/root/bin" ==27444== Nulgrind, the minimal Valgrind tool ==27444== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. ==27444== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==27444== Command: ./mystrncpy /usr/bin:/root/bin ==27444== ==27444== ==27444== Process terminating with default action of signal 11 (SIGSEGV) ==27444== Access not within mapped region at address 0x80025000 ==27444== at 0x80000730: mystrncpy_chk (mystrncpy.c:85) ==27444== by 0x8000052F: main (mystrncpy.c:97) ==27444== If you believe this happened as a result of a stack ==27444== overflow in your program's main thread (unlikely but ==27444== possible), you can try to increase the size of the ==27444== main thread stack using the --main-stacksize= flag. ==27444== The main thread stack size used in this run was 8388608. ==27444== Segmentation fault
Created attachment 83409 [details] Binary as produced with 4.8.2 gcc -march=z10 -g -Wall -O2 -o mystrncpy mystrncpy.c
Does Index: VEX/priv/guest_s390_toIR.c =================================================================== --- VEX/priv/guest_s390_toIR.c (revision 2796) +++ VEX/priv/guest_s390_toIR.c (working copy) @@ -7606,7 +7606,7 @@ put_gpr_dw0(r1, binop(Iop_And64, mkexpr(op2), mkU64(mask))); } assign(result, get_gpr_dw0(r1)); - s390_cc_thunk_putS(S390_CC_OP_LOAD_AND_TEST, op2); + s390_cc_thunk_putS(S390_CC_OP_LOAD_AND_TEST, result); return "risbg"; } fix the problem?
(In reply to comment #3) > Does > Index: VEX/priv/guest_s390_toIR.c > =================================================================== > --- VEX/priv/guest_s390_toIR.c (revision 2796) > +++ VEX/priv/guest_s390_toIR.c (working copy) > @@ -7606,7 +7606,7 @@ > put_gpr_dw0(r1, binop(Iop_And64, mkexpr(op2), mkU64(mask))); > } > assign(result, get_gpr_dw0(r1)); > - s390_cc_thunk_putS(S390_CC_OP_LOAD_AND_TEST, op2); > + s390_cc_thunk_putS(S390_CC_OP_LOAD_AND_TEST, result); > > return "risbg"; > } > > fix the problem? Yes! Thanks. That seems to make everything run fine even when both valgrind preloads and glibc are build with -march=z10
fixed in VEX r2798. Julian, if we do a 3.9.1, this would be a candidate.
Closing.... NEWS updated in r13766