Bug #78927 [Opn->Wfx]: Crash in pcre2_code_free_8, zend_hash_destroy

Edit report at https://bugs.php.net/bug.php?id=78927&edit=1 ID: 78927 Updated by: nikic@php.net Reported by: xnoreq at gmail dot com Summary: Crash in pcre2_code_free_8, zend_hash_destroy -Status: Open +Status: Wont fix Type: Bug Package: Reproducible crash Operating System: Linux 5.3.11 PHP Version: 7.4.0 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2019-12-10 20:19:06] nikic@php.net > 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). ------------------------------------------------------------------------ [2019-12-10 20:13:30] xnoreq at gmail dot com 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. ------------------------------------------------------------------------ [2019-12-10 08:22:05] nikic@php.net 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. ------------------------------------------------------------------------ [2019-12-09 23:47:36] xnoreq at gmail dot com 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.'; } ?> ------------------------------------------------------------------------ [2019-12-09 23:39:41] xnoreq at gmail dot com 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78927 -- Edit this bug report at https://bugs.php.net/bug.php?id=78927&edit=1