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

[Dmitry V. Levin]

On Tue, Jul 09, 2019 at 01:55:30PM +0200, Paul Chaignon wrote:
> On Sun, Jul 07, 2019 at 11:39:13PM +0300, Dmitry V. Levin wrote:
> > On Sun, Jul 07, 2019 at 07:19:07PM +0200, Paul Chaignon wrote:
> > > On Sun, Jul 07, 2019 at 08:06:06PM +0300, Dmitry V. Levin wrote:
> > > > On Sun, Jul 07, 2019 at 05:31:26PM +0200, Paul Chaignon wrote:
> > > > > On Sun, Jul 07, 2019 at 01:25:14PM +0300, Dmitry V. Levin wrote:
> > > > > > On Sat, Jul 06, 2019 at 09:20:15AM +0200, Paul Chaignon wrote:
> > > 
> > > [...]
> > > 
> > > > > > the following behaviour is very likely on that system:
> > > > > > 
> > > > > > $ ../strace -qf -enanosleep ./status-unfinished >/dev/null
> > > > > > [pid 24680] nanosleep({tv_sec=123, tv_nsec=0},  <unfinished ...>
> > > > > > [pid 24681] nanosleep({tv_sec=0, tv_nsec=12345}, NULL) = 0
> > > > > > [pid 24680] <... nanosleep resumed>NULL) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> > > > > 
> > > 
> > > [...]
> > > 
> > > > 
> > > > > As for the ERESTART_RESTARTBLOCK, should we just handle that case in the
> > > > > .c test?
> > > > 
> > > > It's complicated by the fact that we have no information whether that case
> > > > has happened or not.
> > > 
> > > Ah, right.  I don't see what other syscall we can use without risking a
> > > ERESTART_RESTARTBLOCK as well, so should we just try running this test
> > > until it succeeds, kind of like threads-execve.test?
> > 
> > Since the test is about status=unfinished, we want to check that
> > - all unfinished syscalls are printed as expected;
> > - none of syscalls that are not unfinished are printed.
> > 
> > I think we can run it in a kind of loop similar to threads-execve.test
> > with additional check that nothing inappropriate is printed when the
> > actual output does not match the expected output.
> 
> To check that nothing inappropriate is printed, I'm tempted to write a
> reverse match_grep to check that each line of the output are matched by
> one expected pattern.

I'm not sure I understand your idea.

> Another solution could be to check for the above ERESTART_RESTARTBLOCK
> output with the current match_grep.  If we know that's the only expected
> error case, it could be enough.

This is definitely not the only possible scenario.
So far I've seen the following variations of
"../strace -qfenanosleep ./status-unfinished" output:

[pid 25275] nanosleep({tv_sec=123, tv_nsec=0}, NULL) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
[pid 10258] nanosleep({tv_sec=123, tv_nsec=0}, NULL) = -1 (errno 18446744073709551557)
[pid 84169] nanosleep({tv_sec=123, tv_nsec=0}, NULL) = -1 (errno 18446744073709551605)
[pid 23239] nanosleep({tv_sec=123, tv_nsec=0}, ) = ? <unavailable>

> What do you think?  Do you have a cleaner solution?

Well, tests based on threads-execve method are inherently probabilistic.
If we use this method, we have to run a loop and ignore all kinds of
garbage.  In addition to these complicated multi-threaded tests, I suggest
adding a simple single-threaded test for status=unfinished case.

Sometimes tests are getting more complicated than the code they test,
but in this case I'm not sure the complication worths it.


-- 
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/64b64465/attachment.bin>