Subject: bug#24516: closed (Re: bug#24516:)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 23 Sep 2016 18:40:02 +0000

Your bug report

#24516: 

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
24516: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24516
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#24516:
From: Jim Meyering <[email-masked]>
To: "Nelson H. F. Beebe" <[email-masked]>
Cc: [email-masked]
Date: Fri, 23 Sep 2016 11:39:12 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On Fri, Sep 23, 2016 at 8:16 AM, Jim Meyering <[email-masked]> wrote:
> Anyway, thanks for confirming that this simple fix is probably enough.

Adjusted s/3/5/ to be a little more consistent with the above
default-to-5s case, and pushed.

From: Jim Meyering <[email-masked]>
To: [email-masked], "Nelson H. F. Beebe" <[email-masked]>
Date: Thu, 22 Sep 2016 23:00:38 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Nelson Beebe reported that the backref-multibyte-slow test was
failing. From his log, where I saw max_seconds=1, and the following
timeout 1s ... timed out.

I concluded that something (load on the underlying system, disk/kernel
latency) caused that final grep to take far more wall-clock time than
the former one. This would be expected if some other build/test were
running concurrently.

To work around that, I've written the attached: when the timeout would
be just 1s, increase it to 3. In coreutils tests (because there are so
many, and some were so abusive, and running them in parallel...), we
ended up increasing most timeouts to 10s, but for now, that seems like
it'd be overkill here.

I have so far been able to reproduce that failure, so the above is
just an educated guess. If someone can reproduce the failure and test
the patch, that'd be great.