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

[Paul Chaignon]

On Wed, Jul 10, 2019 at 03:54:43AM +0300, Dmitry V. Levin wrote:
> 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.

To check that nothing inappropriate is printed, I wanted to match each
output line against the patterns in .expected.  That way, expected output
lines, such as nanosleep calls or exit_group, would be matched by one of
the patterns.  Unexpected output lines would make the test fail.

>
> > 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>

Ok.

>
> > 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.

Ok.  I added a simple "return 0;" test.

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