Allocation of a negative number of bytes about pcre2

[PhilipHazel]

A look at the Exim bug suggests that this is related to change 9 for 10.41, which says this:

9. Removed the use of an initial backtracking frames vector on the system stack in pcre2_match() so that it now always uses the heap. (In a multi-thread environment with very small stacks there had been an issue.) This also is tidier for JIT matching, which didn't need that vector. The heap vector is now remembered in the match data block and re-used if that block itself is re-used. It is freed with the match data block.

The size of the initial block is 20K. However, I can't see how this could have made PCRE2 ask for >2GB memory. I was going to suggest that perhaps Exim wasn't freeing the match data block when it should, but another look at the Exim bug suggests that this has already been discovered to be the case. I'll leave this comment for the record.

[andrew-aitchison]

This is really to alert the PCRE2 people to [Exim bug 3047] (https://bugs.exim.org/show_bug.cgi?id=3047) which has surfaced because people are using PCRE2 v10.42.

size isn't actually negative; it is >2GB ie INT_MAX and (this may be an Exim bug) Exim is casting it to an int.

We see that PCRE2 v10.42 allocates more space for each file searched than previous versions. When there are many files to be searched the requested allocation may be more than 2GB, which the exim devs feel is wrong. Whilst this is probably an Exim issue, we would appreciate any suggestions that the PCRE2 dev(s) might have.

It would be nice to investigate this so that any change your end can be included when the current PCRE2 beta is released, though I don't think Exim has been tested against your beta.

[PhilipHazel]

Closing as complete.