[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Meyering
Subject: Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30
Date: Tue, 22 Sep 2020 13:12:57 -0700

On Tue, Sep 22, 2020 at 12:39 PM Jim Meyering <> wrote:
> On Tue, Sep 22, 2020 at 10:21 AM Paul Eggert <> 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.

Back to Alpine:

Nelson Beebe reported that grep's "file" test failed on an Alpine
3.6.4 system. I tracked the failure to a bug in the musl wcrtomb
function that has apparently been fixed by now.

I had to build like this because the default shell wouldn't make it
past very early configure integrity checks:
CONFIG_SHELL=/bin/bash ./configure && make CFLAGS='-O1 -g'

Here's the reduced reproducer:
LC_ALL=C src/grep -i MI < /dev/null

It evokes this:
Program received signal SIGILL, Illegal instruction.
wcrtomb (__st=0x764d3fbfa5c0, __w=<optimized out>, __s=0x764d3fbfa650
"m") at /usr/include/fortify/wchar.h:113

When I told configure to use gnulib's wcrtomb function via this, that
test passes:
CONFIG_SHELL=/bin/bash ./configure ac_cv_func_wcrtomb=no

Considering that the 3.6 series went past end-of-life more than a year
ago, per, and that I've
just provided a simple configure-time work-around, it feels like it's
not worth pursuing further.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]