[PATCH v7 4/4] tests: check status qualifier
Paul Chaignon
paul.chaignon at gmail.com
Tue Jul 9 11:55:30 UTC 2019
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.
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.
What do you think? Do you have a cleaner solution?
Paul
More information about the Strace-devel
mailing list