All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: "Paul Eggert" <eggert@cs.ucla.edu>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: improve performance of PCRE2 bug 2642 bug workaround
Date: Wed, 23 Mar 2022 19:37:22 +0100	[thread overview]
Message-ID: <1187feda-c14a-f75c-6e09-4df101f00056@web.de> (raw)
In-Reply-To: <20220323010931.jzf7op7hdusdty33@carlos-mbp.lan>

Am 23.03.22 um 02:09 schrieb Carlo Marcelo Arenas Belón:
> On Tue, Mar 22, 2022 at 09:26:10PM +0100, René Scharfe wrote:
>> Am 22.03.22 um 17:38 schrieb Paul Eggert:
>>> Today, Carlo Arenas pointed out[1] that GNU grep didn't work around
>>> PCRE2 bug 2642, which Git grep has a workaround for. While installing
>>> a GNU grep patch to fix this[2] I noticed that Git's workaround
>>> appears to be too pessimistic: on older PCRE2 libraries Git grep sets
>>> PCRE2_NO_START_OPTIMIZE even when PCRE2_CASELESS is not set.
>>
>> Interesting.  So you say bug 2642 [3] requires the flag PCRE2_CASELESS
>> (i.e. --ignore-case) to be triggered.  (That's probably documented in
>> Bugzilla, but I'm not authorized to access it.)
>
> AFAIK the contents of the bugzilla are no longer accessible to anyone
> (lost in the migration of PCRE2 to github), but the use of
> PCRE2_CASELESS introduced in 95ca1f987e (grep/pcre2: better support
> invalid UTF-8 haystacks, 2021-01-24) might had been a mistake all
> along.

Ah, OK.

> the bug will trigger when both PCRE2_UTF and PCRE2_MULTILINE are set
> (as shown in the PCRE2 regression added), with the later set by
> default in git and NEVER set in GNU grep, hence why I later
> retracted[6] my suggestion to add the workaround to grep, and suggest
> updating git with the following
> Carlo
>
> [6] https://lists.gnu.org/r/grep-devel/2022-03/msg00006.html
> --- >8 ---
> Subject: [PATCH] grep: remove check for case sensitivity in workaround for
>  PCRE's bug2642
>
> 95ca1f987e (grep/pcre2: better support invalid UTF-8 haystacks, 2021-01-24)
> add a workaround to an old PCRE2 bug, but includes in the logic a partial
> check for case sensitivity without explanation.
>
> Remove it so that the workaround (and its performance impact) will be only
> triggered when needed (both PCRE2_MULTILINE and PCRE2_UTF and JIT is used)
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
>  grep.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/grep.c b/grep.c
> index 82eb7da102..d910836569 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -296,8 +296,8 @@ static void compile_pcre2_pattern(struct grep_pat *p, const struct grep_opt *opt
>  		options |= (PCRE2_UTF | PCRE2_MATCH_INVALID_UTF);
>
>  #ifndef GIT_PCRE2_VERSION_10_36_OR_HIGHER
> -	/* Work around https://bugs.exim.org/show_bug.cgi?id=2642 fixed in 10.36 */
> -	if (PCRE2_MATCH_INVALID_UTF && options & (PCRE2_UTF | PCRE2_CASELESS))
> +	/* Work around PCRE2 bug2642 fixed in 10.36 */
> +	if (SUPPORT_JIT && PCRE2_MATCH_INVALID_UTF && (options & PCRE2_UTF))

SUPPORT_JIT can be undefined and then this won't compile.

And if I turn it into an "#ifdef SUPPORT_JIT", t7812.16 fails with PCRE2
versions 10.34 and 10.35.

SUPPORT_JIT is defined in PCRE2's config.h and not baked into any of its
public headers, so it never will be set in grep.c, right?  Perhaps just
drop this condition?

The patch below adds a test that fails even with a PCRE2 configured with
--disable-git.  Current main passes this test even with PCRE2 versions
10.34 and 10.35.

"PCRE2_MATCH_INVALID_UTF && (options & PCRE2_UTF)" can be simplified to
"options & PCRE2_MATCH_INVALID_UTF".

>  		options |= PCRE2_NO_START_OPTIMIZE;
>  #endif
>

--- >8 ---
Subject: [PATCH] t7812: test PCRE2 whitespace bug

Check if git grep works around the PCRE2 big fixed by their e0c6029
(Fix inifinite loop when a single byte newline is searched in JIT.,
2020-05-29), which affects version 10.35 and earlier.

Searching for leading whitespace also triggers the endless loop.
Set a one-second alarm to abort in case we do get hit by the bug, to
avoid having to wait forever for the test result.

Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
---
 t/t7812-grep-icase-non-ascii.sh | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/t/t7812-grep-icase-non-ascii.sh b/t/t7812-grep-icase-non-ascii.sh
index 9047d665a1..ac7be54714 100755
--- a/t/t7812-grep-icase-non-ascii.sh
+++ b/t/t7812-grep-icase-non-ascii.sh
@@ -4,6 +4,10 @@ test_description='grep icase on non-English locales'

 . ./lib-gettext.sh

+doalarm () {
+	perl -e 'alarm shift; exec @ARGV' -- "$@"
+}
+
 test_expect_success GETTEXT_LOCALE 'setup' '
 	test_write_lines "TILRAUN: Halló Heimur!" >file &&
 	git add file &&
@@ -139,4 +143,10 @@ test_expect_success GETTEXT_LOCALE,LIBPCRE2 'PCRE v2: grep non-literal ASCII fro
 	test_cmp expected actual
 '

+test_expect_success GETTEXT_LOCALE,LIBPCRE2 'PCRE v2: grep avoid endless loop bug' '
+	echo " Halló" >leading-whitespace &&
+	git add leading-whitespace &&
+	doalarm 1 git grep --perl-regexp "^\s" leading-whitespace
+'
+
 test_done
--
2.35.1

  parent reply	other threads:[~2022-03-23 18:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 16:38 improve performance of PCRE2 bug 2642 bug workaround Paul Eggert
2022-03-22 20:26 ` René Scharfe
2022-03-22 21:12   ` Paul Eggert
2022-03-23  1:09   ` Carlo Marcelo Arenas Belón
2022-03-23  4:06     ` Paul Eggert
2022-03-23 18:37     ` René Scharfe [this message]
2022-03-23 20:24       ` Carlo Arenas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1187feda-c14a-f75c-6e09-4df101f00056@web.de \
    --to=l.s.r@web.de \
    --cc=avarab@gmail.com \
    --cc=carenas@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.