https://bugs.kde.org/show_bug.cgi?id=408414
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
Ever confirmed|0 |1
CC| |m...@klomp.org
--- Comment #5 from Mark Wielaard <m...@klomp.org> ---
We discussed the last version of this patch on irc. It had mismatched .exp
files, but this was easily fixed. I did update the printing of the vector from
vector[...] to include the actual index.
The new test case is nice because it shows the current valgrind pwritev
handling can crash:
$ valgrind -q memcheck/tests/linux/sys-preadv_pwritev
==21111== Syscall param pwritev(vector) points to unaddressable byte(s)
==21111== at 0x4F2AC7A: pwritev (pwritev.c:42)
==21111== by 0x400BDE: main (sys-preadv_pwritev.c:53)
==21111== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==21111==
==21111== Syscall param pwritev(vector) points to unaddressable byte(s)
==21111== at 0x4F2AC7A: pwritev (pwritev.c:42)
==21111== by 0x400BF6: main (sys-preadv_pwritev.c:54)
==21111== Address 0xffffffffffffffff is not stack'd, malloc'd or (recently)
free'd
==21111==
--21111-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--21111-- si_code=1; Faulting address: 0xFFFFFFFFFFFFFFFF; sp: 0x1003283d70
valgrind: the 'impossible' happened:
Killed by fatal signal
host stacktrace:
==21111== at 0x580B9FFC: vgSysWrap_linux_sys_pwritev_before
(syswrap-linux.c:5422)
==21111== by 0x5809767F: vgPlain_client_syscall (syswrap-main.c:1857)
==21111== by 0x58094372: handle_syscall (scheduler.c:1126)
==21111== by 0x58095786: vgPlain_scheduler (scheduler.c:1443)
==21111== by 0x580A4C2A: UnknownInlinedFun (syswrap-linux.c:103)
==21111== by 0x580A4C2A: run_a_thread_NORETURN (syswrap-linux.c:156)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 21111)
==21111== at 0x4F2AC7A: pwritev (pwritev.c:42)
==21111== by 0x400BF6: main (sys-preadv_pwritev.c:54)
This is fixed with Sasha's patch.
The testcase also tries to test handling an uninitialized flag argument for the
v2 syscall.
But to our surprise this didn't work... The flag always came out as defined
zero.
Turns out glibc does this deliberately on 64bit architectures because the
kernel does actually have a low_offset and high_offset argument, but ignores
the high_offset/assumes it is zero...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=601cc11d054ae4b5e9b5babec3d8e4667a2cb9b5
There is a fixed up version here:
https://code.wildebeest.org/git/user/mjw/valgrind/commit/?h=pvrw2
Not tested yet were non-x86_64 architectures, but I think we should just hook
up the other linux arches (the nightly builders will alert us if they behave
differently).
--
You are receiving this mail because:
You are watching all bug changes.
