If a locale other than C is active, character tables are saved into the
compile context. Every compiled pattern will have a pointer to the
character table, that was present in the context at the time of the
pattern compilation. Thus, the cache entries don't need to carry char
tables pointer, which reduces their size to 8 bytes on 64-bit. Instead,
the generated character tables are tracked in a separate HashTable. If a
character table was generated before, it'll be assigned to the compile
context when the locale changes. Otherwise a new char table will be
generated and cached.
PCRE 8.x initializes the pattern compiler on demand during the first
pcre_study call. It could be worse, but since the compiled patterns are
cached, the locking impact is minimal. PCRE 10.x always compiles the
pattern and thread sanitizer doesn't complain about the compiler
initialization, thus the newer PCRE version seems to be unafected.
If (*NO_JIT) is put into the pattern, the JIT compilation will still
succeed but produce no code. The pattern will still have to be
interpreted and is not suitable for the JIT fast path. This means,
we still need to check the pattern info after JIT compilation and only
set the flags when the JIT code was produced.
In this case it loops through different subjects without looking for sub
matches and matches are done against the same pattern. Thus, don't reset
the UTF check flag but use it to check whether JIT should be used and
otherwise let PCRE to do the job according to what was saved into the
pattern.
HEADSUP! With PCRE 8.39 the JIT related code was changed in the way,
that additional valgrind options became almost unavoidable. Valgrind
had it already sometimes hard with JIT, now there are seem to be more
cases requiring special valgrind options.
For this reason, the new configure option --with-pcre-valgrind was
introduced. The option is development/debugging only and turns on the
Valgrind related pieces in PCRE, so then false positives are avoided
to the big part. In addition, run-tests.php was added a new valgrind
option, when the leak check is enabled and the test filepath contains
pcre.
Thus, to debug the code related to PCRE with JIT enabled, two things
would likely make sense
- configure --with-pcre-valgrind
- valgrind option --smc-check=all if run-tests.php is not used
The checks so far reveal no new issues.
