It looks to me like for some reason the per-request PCRE cache gets shut down, even though FPM shouldn't be using it.

Based on code inspection alone, I don't see what the issue could be.

This is tiny tiny rss's update script (update_daemon2.php) which is a cli executable. That's why the process name is also php (and not php-cgi or php-fpm).

It forks off do to multiple updates in parallel and I guess that leads to the invalid frees.

Thanks, the trace makes much more sense with this being a cli executable.

fork() in most cases shouldn't matter, but here there might be a possible interference with the JIT mapped memory used by PCRE.

Which Linux distro are you using and do you know how they build their PCRE binaries? If they are using --enable-sealloc, then this may indeed be incompatible with fork().

Which PHP version did you use before the upgrade? PHP 7.3 or something older?

I was using 7.3.12 before.

You can find the build files and patches here:
https://git.archlinux.org/svntogit/packages.git/tree/repos/extra-x86_64?h=packages/php

There's no --enable-sealloc option.

Here's a simple test-case to reproduce the issue:

$ php -f test.php

test.php:
<?php
function regex() {
        preg_match('/(foo)(bar)(baz)/', 'foobarbaz', $matches, PREG_OFFSET_CAPTURE);
}

regex();

$pid = pcntl_fork();
if ($pid == -1) {
        die('error.');
}
else if ($pid) {
        echo 'parent... ';
        pcntl_wait($pid);
        echo 'wait done';
}
else {
        echo 'child.';
}
?>

The --enable-sealloc flag is passed when building libpcre2 rather than PHP. Looking through the repository you linked, it seems that they indeed use this flag: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pcre2#n31

This compilation option is known to be incompatible with fork(), causes a range of other issues, and its use is discouraged by PCRE upstream. If you can, please petition ArchLinux to remove this flag and instead properly grant JIT permissions (W+X mmap) to programs that use PCRE JIT.

Some references for issues this has caused:
https://bugs.php.net/bug.php?id=78630 (tmp mounted noexec)
https://bugs.exim.org/show_bug.cgi?id=1749 (the fork issue is mentioned here)
https://bugs.exim.org/show_bug.cgi?id=2445 (breaks under low disk conditions)

What isn't clear to me is why you're seeing this issue only on PHP 7.4, as it principally should affect PHP 7.3 (also using PCRE2) as well.

For now, you can work around this issue by setting pcre.jit=0 for the script that uses forking.

Thanks, I have recompiled pcre2 without --enable-sealloc and now there are no more crashes.

I have also created a bug report in Arch Linux's bug tracker:
https://bugs.archlinux.org/task/64799

It looks like the change was made to fix the incompatibility with the new MemoryDenyWriteExecute=true in the php-fpm.service.

As I wrote, this does not seem like the right solution to me. Instead, Arch should either change php.ini to disable pcre.jit by default or patch the service file to disable MemoryDenyWriteExecute by default.

> It looks like the change was made to fix the incompatibility with the new MemoryDenyWriteExecute=true in the php-fpm.service.
>
> As I wrote, this does not seem like the right solution to me. Instead, Arch should either change php.ini to disable pcre.jit by default or patch the service file to disable MemoryDenyWriteExecute by default.

If this was just done to satisfy the php-fpm.service definition: MemoryDenyWriteExecute=true was enabled by mistake there, and this has been reverted by https://github.com/php/php-src/commit/67cd4271e922ee3082b416a7563598274d13a1e5 in the meantime (part of 7.4.1).

I'm closing this bug as I don't think there is anything actionable here on the PHP side. The MemoryDenyWriteExecute=true flag has already been removed from the service definition, and we can't do anything about fork() limitations when PCRE is built with --enable-sealloc.