This issue is apparently locale related. For instance, the script works
fine if the locale is "C", see <https://3v4l.org/4IVgb>. Alternatively,
commenting out line 58[1] will also let the script succeed.

Anyhow, the behavioral change had been introduced with commit
4514ba01[2].

Dmitry, can you please have a look at this issue?

[1] <https://gist.github.com/xknown/b0bdcfa87edf039e995822d86cfde441#file-segfault-php-L58>
[2] <http://git.php.net/?p=php-src.git;a=commit;h=4514ba016ff158cd113deef1a215fcdcb6913b48>

After looking a little bit more into this issue I think this happens because the update logic of already cached items doesn't really take into account locale changes.

For example, if a regex A was cached with locale X, then `pcre_get_compiled_regex_cache ` will store it as `H(x, compiled(A))`. If this cached value is still in use (i.e. preg_replace_callback in the provided script) AND the locale changes to Y, then `pcre_get_compiled_regex_cache` will update the entry `H(x, compiled(B))` (via zend_hash_update_mem), this will override the refere that's still in use for `H(x, compiled(A))`.

I added a naive patch that uses a combination of regex+locale (if available) which seems to fix this issue.

I got another patch, which could get rid of the pce->locale checks at all.

https://gist.github.com/laruence/44287a993205fe0ac75321db959ea121

thanks

And a simpler reproduce script:

<?php
$regex = "#dummy#";
setlocale(LC_ALL, "C");
preg_replace_callback($regex, function (array $matches) use($regex) {
    setlocale(LC_ALL, "en_US");
    preg_replace($regex, "A", "A");
    setlocale(LC_ALL, "C");
}, "dummy");

Thanks. I am not longer able to reproduce this issue with the patch above.