Jim Meyering wrote:
after your change,
our pcre-invalid-utf8-input hangs. That happens because the following
infloops (stuck in pcre_exec) on a CentOS6 system:
printf 'j\202j\nj\nk\202\n' > in; LC_ALL=en_US.utf8 src/grep -P 'k$' in
That binary was linked with the libpcre from this package:
pcre-7.8-4.el6.x86_64
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?
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.
diff --git a/tests/pcre-invalid-utf8-input b/tests/pcre-invalid-utf8-input
index 78bd1cf..71d4877 100755
--- a/tests/pcre-invalid-utf8-input
+++ b/tests/pcre-invalid-utf8-input
@@ -9,21 +9,23 @@
. "${srcdir=.}/init.sh"; path_prepend_ ../src
require_pcre_
+require_timeout_
require_en_utf8_locale_
+require_compiled_in_MB_support
fail=0
printf 'j\202j\nj\nk\202\n' > in || framework_failure_
-LC_ALL=en_US.UTF-8 grep -P j in
+LC_ALL=en_US.UTF-8 timeout 3 grep -P j in
test $? -eq 0 || fail=1
-LC_ALL=en_US.UTF-8 grep -P 'k$' in
+LC_ALL=en_US.UTF-8 timeout 3 grep -P 'k$' in
test $? -eq 1 || fail=1
echo k >exp
-LC_ALL=en_US.UTF-8 grep -aoP 'k*' in >out || fail=1
+LC_ALL=en_US.UTF-8 timeout 3 grep -aoP 'k*' in >out || fail=1
compare exp out || fail=1
Exit $fail
