[PATCH v7 4/4] tests: check status qualifier

[Dmitry V. Levin]

On Wed, Jul 10, 2019 at 03:52:46PM +0200, Paul Chaignon wrote:
> On Wed, Jul 10, 2019 at 04:06:49AM +0300, Dmitry V. Levin wrote:
> 
> [...]
> 
> > After quit some time I managed to get the following:
> > $ uname -a
> > Linux lgentoo4 4.16.11 #1 SMP Fri May 25 06:41:48 EDT 2018 s390x 2964 IBM GNU/Linux
> > $ ../strace -qfenanosleep ./status-none >/dev/null
> > [pid 21584] nanosleep({tv_sec=123, tv_nsec=0}, NULL) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> > [pid 21584] syscall_0x3ff96e52800(0x3ffef1ff5e3, 0x3ff96d7efc8, 0, 0x3ff00000000, 0x3ff96d7f910, 0x3ffef1fea67) = 0x2d
> > [pid 21584] syscall_0x24549000(0, 0x3ffee8ff038, 0x3ff926179bc, 0x1000c28, 0x3ff92625f98, 0x3ff92600ea0) = 0x5a
> > [pid 21584] syscall_0x3ff9267c000(0x3ffee8fe748, 0x2000, 0x3, 0x22, 0xffffffffffffffff, 0x6) = 0x21
> > [pid 21584] syscall_0xfffffffffffffffe(0x3ff9261e83e, 0x4, 0x6, 0x3ff92626000, 0x3ff9267e2e1, 0x3ff926270e0) = 0x120
> > [pid 21584] syscall_0xfffffffffffff000(0x3, 0x3ffee8fdc20, 0x3ffee8fdc20, 0, 0, 0) = 0x5a
> > [pid 21584] syscall_0x3ff92580000(0x3ffee8fdb48, 0x57c1, 0x1, 0x2, 0x3, 0) = 0x6
> > [pid 21584] syscall_0xfffffffffffff000(0x3, 0x57c1, 0x1, 0x2, 0x3, 0) = 0x120
> > [pid 21584] syscall_0x340(0x3, 0x3ffee8fdec0, 0x340, 0, 0, 0x3ff9267c7e0) = 0x6c
> > [pid 21584] syscall_0x3ff926270a8(0x3, 0x3ffee8fdce8, 0x3ffee8fdce8, 0x3ffee8fdeb8, 0x3ff9267c7e0, 0x1) = 0x5a
> > [pid 21584] syscall_0x3ff92500000(0x3ffee8fd9c0, 0x234c8, 0x5, 0x802, 0x3, 0x3ffee8fdad0) = 0x5a
> > [pid 21584] syscall_0x3ff9251e000(0x3ffee8fd9c0, 0x2000, 0x3, 0x812, 0x3, 0x3ffee8fdad0) = 0x5a
> > [pid 21584] syscall_0x3ff92520000(0x3ffee8fd9c0, 0x34c8, 0x3, 0x32, 0xffffffffffffffff, 0x3ffee8fdad0) = 0x6
> > [pid 21584] syscall_0x340(0x3, 0x3ffee8fdea0, 0x340, 0, 0, 0x3ff9267ccd0) = 0x6c
> > [pid 21584] syscall_0x3ff926270a8(0x3, 0x3ffee8fdcc8, 0x3ffee8fdcc8, 0x3ffee8fde98, 0x3ff9267ccd0, 0x1) = 0x5a
> > [pid 21584] syscall_0x3ff92300000(0x3ffee8fd970, 0x1b5720, 0x5, 0x802, 0x3, 0x3ffee8fda80) = 0x5a
> > [pid 21584] syscall_0x3ff924ac000(0x3ffee8fd970, 0x6000, 0x3, 0x812, 0x3, 0x3ffee8fda80) = 0x5a
> > [pid 21584] syscall_0x3ff924b2000(0x3ffee8fd970, 0x3720, 0x3, 0x32, 0xffffffffffffffff, 0x3ffee8fda80) = 0x6
> > [pid 21584] syscall_0x3ff924acde8(0x3, 0, 0x3ff92300290, 0x6fffffff, 0x6ffffeff, 0x6ffffdff) = 0x5a
> > [pid 21584] syscall_0x3ff9267a000(0x3ffee8fe848, 0x2000, 0x3, 0x22, 0xffffffffffffffff, 0x3ff926270e0) = 0x7d
> > [pid 21584] syscall_0x3ff924ac000(0x3ff924ac000, 0x4000, 0x1, 0x3ff924b0000, 0x3ff92300000, 0x3ff9267ccf0) = 0x7d
> > [pid 21584] syscall_0x3ff9251e000(0x3ff9251e000, 0x1000, 0x1, 0x3ff9251f000, 0x3ff923988b0, 0x3ff9267c800) = 0x7d
> > [pid 21584] syscall_0x1002000(0x1002000, 0x1000, 0x1, 0x1003000, 0, 0x3ff926270e0) = 0x7d
> > [pid 21584] syscall_0x3ff92625000(0x3ff92625000, 0x1000, 0x1, 0x3ff92626000, 0x3ff92397ee8, 0x3ff92626988) = 0x5b
> > [pid 21584] syscall_0x3ff9257ffff(0x3ff92580000, 0x57c1, 0x3ff926270e0, 0x3ff92626000, 0, 0x3ff926270e0) = 0xfc
> > [pid 21584] syscall_0x5450(0x3ff9267a7f0, 0x3ffee8feef8, 0x3ff9267a720, 0x3ffee8fef10, 0x3ffee8fef10, 0x3ffee8fef10) = 0x130
> > [pid 21584] syscall_0x3ff9267a720(0x1, 0x3ffee8febe8, 0, 0x8, 0x3ffee8fef10, 0x3ffee8fef10) = 0x14e
> > [pid 21584] syscall_0x5450(0, 0x3ff9267a720, 0x1000b5c, 0x3ff924acec8, 0x1001150, 0x3ffee8feee0) = 0x4
> > [pid 21584] syscall_0x1c(0x1, 0x3ffee8fc510, 0x1c, 0x3ff924b56a0, 0x3ff924acec8, 0x1c) = 0xf8
> > [pid 21584] +++ exited with 0 +++
> > ../strace: wait4(__WALL): No child processes
> >
> > This was the version of status-none with clock_nanosleep and without
> > nanosleep in thread().  There was no "Stray PTRACE_EVENT_EXEC" message
> > and strace apparently got confused between syscall entering and exiting.
> 
> I'm not quite sure what to make of this.  Do you think this is a bug
> introduced by this patchset?

No, I'm pretty sure it can be reproduced without this patchset, too.

> I have seen such bugs (syscall entry/exit
> confusion) with the seccomp patchset, but never with this one.  Do you
> have a way to reproduce?

I had to run the test in a loop on that s390x box for quite some time,
and 1 of 25756 iterations ended up with that mess, that's all I know.

I couldn't reproduce this on x86_64 or ppc64le, though.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190710/b7886da2/attachment.bin>