Subject: Re: Suspected git grep regression in git 2.40.0

From: Junio C Hamano <[email-masked]>
Date: Tue, 21 Mar 2023 09:33:37 -0700

[jc: on the CC: line, summoned a few people who may know a lot more
about pcre than I do]

Stephane Odul <[email-masked]> writes:

> We have a CI pipeline on a private repository that started failing
> consistently while running `git grep -P` commands. The command
> fails with an exit code of -11 and is failing pretty
> consistently. With prior versions of git there is no issue
> whatsoever, but with 2.40.0 it always fails on the same
> call. Other git grep calls are fine, but that one is failing
> consistently.
>
> I was not able to reproduce locally but my main machine is an M1
> MacBook Pro, the CI pipeline runs under Kubernetes in AWS and the
> container is based on Ubuntu 20.04 with the git client installed
> via the PPA.
>
> The error is for this pattern `git grep -cP '^\w+ = json.load'`.
>
> As a workaround we tried to download and install the microsoft-git
> v2.39.2 deb package since it allows us to downgrade, but then the
> git grep commands just got stuck.

One "grep -P" related change we had recently between 2.39 and 2.40
was

    50b6ad55 (grep: fall back to interpreter if JIT memory
    allocation fails, 2023-01-31)

The code tries to figure out at runtime if pcre engine has
functioning JIT by making an extra JIT compilation of a sample
pattern and when it fails with a specific reason, fall back to
interpreted pattern matching.  The change made the code to emit a
bit more detailed information when it fails, but a controlled exit
from the codepath should give $?=128, not 11.

So the above commit may or may not be related.  It could be that the
version of pcre library linked to Git 2.40 and older Git you are
running in your CI environment has been updated.

Does it make a difference if you disable JIT by prefixing the
pattern with (*NO_JIT)?

Thanks.