bug#18806: grep -rP getline crashes prematurely (without displaying all results) on invalid UTF-8 input with LC_ALL=en_US.UTF-8

[Jim Meyering]

On Sat, Oct 25, 2014 at 4:11 PM, Paul Eggert <address@hidden> wrote:
> I'm getting a failure in pcre-invalid-utf8-input both before and after the
> change, with CentOS 6.5 and pcre-7.8-6.el6.x86_64.  In my case the failures
> are segmentation violations; perhaps 7.8-4 has a different failure mode, or
> perhaps there's some other minor change to your platform that causes libpcre
> to infloop.  Either way, this appears to be a PCRE bug that grep can't be
> expected to work around.
>
> Does the attached patch cause the test to fail reliably for you, instead of
> looping?

Yes.  And a timeout of 3s should be fine.  Thanks.  Please push that.

I've just built grep against the latest pcre from git (an Oct 10 commit with
this hash: cc48a55a5de9c2103f6657147149bcf63ff61579), and then all
of grep's tests pass.

Ideally, we would detect and warn about inadequate versions of pcre,
but that certainly need not block the release.

> By the way, I'm not sure why tests distinguish between
> require_en_utf8_locale_ and require_compiled_in_MB_support; the latter
> requires the former, and there's no point requiring the former unless we
> also require the latter.

It looks like I added the require_compiled_in_MB_support function in
grep commit v2.9-27-g46e5cc6, yet never realized that it subsumed
require_en_utf8_locale_.  You're welcome to clean up after the release.