Bug #78630 [Com]: PHP 7.3 preg_match(): JIT compilation failed: no more memory (need pcre.jit=0)

Edit report at https://bugs.php.net/bug.php?id=78630&edit=1 ID: 78630 Comment by: build+suse at de-korte dot org Reported by: ilya at ilya dot pp dot ua Summary: PHP 7.3 preg_match(): JIT compilation failed: no more memory (need pcre.jit=0) Status: Open Type: Bug Package: PCRE related Operating System: openSUSE Tumbleweed PHP Version: 7.3.10 Block user comment: N Private report: N New Comment: Note that openSUSE Tumbleweed uses a private /tmp, which is mounted under /var/tmp/systemd-private-[lots of hex]-php-fpm.service-[more hex]/tmp. So if you have mounted your /var partition as no-exec, the private /tmp your PHP process is using will also be no-exec. Previous Comments: ------------------------------------------------------------------------ [2019-10-04 10:35:58] nikic@php.net Thanks for the strace logs! The relevant part is: openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_NOATIME|O_CLOEXEC|O_TMPFILE, 0600) = 5 ftruncate(5, 65536) = 0 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x7f33788e9000 mmap(NULL, 65536, PROT_READ|PROT_EXEC, MAP_SHARED, 5, 0) = -1 EPERM (Операция не позволена) munmap(0x7f33788e9000, 65536) = 0 close(5) = 0 The PROT_READ|PROT_EXEC mmap fails with EPERM. Apart from the possibility of this being prevented by something like SELinux, the man page also lists two more possibilities: EPERM The prot argument asks for PROT_EXEC but the mapped area belongs to a file on a filesystem that was mounted no-exec. EPERM The operation was prevented by a file seal; see fcntl(2). Could you check whether the /tmp filesystem might be mounted as noexec? (This should be visible in the output of "mount".) ------------------------------------------------------------------------ [2019-10-04 10:15:05] ilya at ilya dot pp dot ua @nikic Thank you, I did it. Received strange results. At the first start (php processes do not exist yet), an error always appears, and moreover, when you refresh the php page once everything is fine, then again this error. Attached strace output from both processes after an error. https://bugzilla.suse.com/attachment.cgi?id=820531 https://bugzilla.suse.com/attachment.cgi?id=820532 ------------------------------------------------------------------------ [2019-10-04 07:54:57] nikic@php.net > This is also problematic, I never used strace. > Can you give detailed instructions on how to do it? Run "sudo strace -p PID", where PID is a php-fpm process ID and then access the phpmyadmin page. (Or possibly a php-fastcgi process ID, I have no idea what that is.) ------------------------------------------------------------------------ [2019-10-04 07:49:09] build+suse at de-korte dot org I'm running php-7.3.10 on openSUSE Tumbleweed too and see no problems with 'pcre.jit = 1' and phpMyAdmin. I too use the mpm_event and have an identical memory_limit (128M) for PHP as the reporter. I do run php-fpm through mod_proxy_fcgi though and not through mod_fcgid + php-fastcgi. I think it is safe to assume that the problems the OP is seeing, is not going to be solved by upgrading to 7.4.0RC3. ------------------------------------------------------------------------ [2019-10-03 21:33:06] nikic@php.net Thanks for the information. As the PCRE2 build uses --enable-jit-sealloc (which sets SLJIT_PROT_EXECUTABLE_ALLOCATOR) and the PHP build uses the system PCRE2 build, this means that preg_* should end up using the ProtExec allocator, which is W^X compatible. So the problem here might be the other way around, and the use of the ProtExec allocator is what causes the issue. Looking at recent pcre-dev posts, I saw the discussion in https://bugs.exim.org/show_bug.cgi?id=2445, which looks potentially relevant. ------------------------------------------------------------------------ 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=78630 -- Edit this bug report at https://bugs.php.net/bug.php?id=78630&edit=1