On Fri, Aug 12, 2016 at 11:02:14AM +0100, James Cowgill wrote:
[...]
> >> The only test which still seems to fail on my machine is the "pwritev"
> >> test,
> >> but I believe that's caused by a kernel bug (which I haven't tracked down
> >> yet).
> >
> > Does this patch changes something with the test result?
> > (also add #include <errno.h> to make it buildable)
> >
> > --- a/tests/pwritev.c
> > +++ b/tests/pwritev.c
> > @@ -113,6 +113,7 @@ main(void)
> > unsigned int n = LEN + 1 - i;
> > fputs("pwritev(0, ", stdout);
> > print_iovec(iov + i, n, LEN - i);
> > + errno = 0;
> > rc = pwritev(0, iov + i, n, offset + LEN + i);
> > printf(", %u, %lld) = %ld %s (%m)\n",
> > n, (long long) offset + LEN + i, rc, errno2name());
>
> So before it was failing with:
> 10c10
> < pwritev(0, [{iov_base="\1\2\3\4\5\6\7", iov_len=7},
> {iov_base="\2\3\4\5\6\7", iov_len=6}, {iov_base="\3\4\5\6\7",
> iov_len=5}, {iov_base="\4\5\6\7", iov_len=4}, {iov_base="\5\6\7",
>
> iov_len=3}, {iov_base="\6\7",
> iov_len=2}, {iov_base="\7", iov_len=1}, 0xfff0fb8000], 8,
> 1004211379570065144) = 27 EFAULT (Bad address)
> ---
> > pwritev(0, [{iov_base="\1\2\3\4\5\6\7", iov_len=7},
> {iov_base="\2\3\4\5\6\7", iov_len=6}, {iov_base="\3\4\5\6\7",
> iov_len=5}, {iov_base="\4\5\6\7", iov_len=4}, {iov_base="\5\6\7",
>
> iov_len=3}, {iov_base="\6\7",
> iov_len=2}, {iov_base="\7", iov_len=1}, 0xfff0fb8000], 8,
> 1004211379570065144) = 27
> pwritev.test: failed test: ../strace -e trace=pwritev -a22 -s7 ./pwritev
> output mismatch
>
> After adding errno = 0 it fails with:
> unknown errno 0Does this also happen when pwritev is executed without strace? > How did you know that was where my error was :) I thought it was a > kernel bug since I think the pwritev call should fail with EFAULT. I > also noticed that the call only succeeds if the process is being ptraced. The test tries hard to make this particular syscall end with EFAULT by passing it an array of struct iovec that starts at mapped memory and ends at unmapped memory. As you can see, strace is deliberately unable to fetch the last element of this array at address 0xfff0fb8000 so it just prints the address. This is expected behaviour. The strange thing is that the kernel has ignored this obstacle and has returned 27, which is 1 byte less than expected 28 if pwritev was called with 3rd argument set to 7 instead of 8. So yes, the kernel is really expected to fail with EFAULT, and it looks like a kernel bug that it doesn't. ;) -- ldv
pgpKVCCML3Qju.pgp
Description: PGP signature
------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
