Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30

[Jim Meyering]

On Tue, Sep 22, 2020 at 10:21 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 9/22/20 10:03 AM, Bruno Haible wrote:
> > Paul Eggert wrote:
> >> Well that's bogus. Does the attached patch work around the bug on Alpine?
> >
> > Yes. It causes the grep-dev-null-out test to become SKIP instead of FAIL.
>
> Thanks for checking, and I installed the patch into grep master.
>
> I think this addresses all issues brought up so far by snapshot feedback.

Thanks for all your work!

Unfortunately, that test: (requiring 124 exit from `timeout 0.01 sleep
0.02`) is racy. Sometimes, e.g., when run on a heavily-loaded system,
even gnu timeout may exit 0.
In coreutils tests, we found that even a 3- or 5-second margin was
sometimes insufficient, so we made most "timeout $N"-using tests use
N=10.

Clearly, sleeping multiple seconds at the start of each test is not
the right solution.

Also, I've just noticed that these invocations all exit with status 0
using GNU coreutils on OS X 10.15.6:
timeout .1 sleep .2
timeout .1 sleep .9
timeout .1 sleep .99

Yet sleeping for 1 second or longer DOES evoke the expected exit code
of 124. From the following you can guess that there is something
significant about the 1-second duration of the child process:

$ while :; do timeout .1 sleep .994; case $? in 124) m=x;; *)m=.;;
esac; printf $m; done
xxx...x.x............x...x....xx..x.x.xx..xxxx..x..x..xxxx..xx.xxxx....x

This may have exposed a bug in coreutils' timeout on that system.