JIT segmentation fault in PHP 8.1

Description

PHP 8.1.0 + 8.1.1 produces segfault, randomly. Downgrading to 8.0 solves the issue.

--core dump---

BFD: Warning: coredump-php-fpm.30267 is truncated: expected core file size >= 5413076992, found: 35983360.
[New LWP 30267]
[New LWP 1887]
[New LWP 1886]
[New LWP 1888]
Cannot access memory at address 0x7f277dbb3128
Cannot access memory at address 0x7f277dbb3120
Failed to read a valid object file image from memory.
Core was generated by `php-fpm: pool xxxxxx '.

Program terminated with signal 11, Segmentation fault.
#0 0x000055bbf04c0f25 in ZEND_NEW_SPEC_CONST_UNUSED_HANDLER () at /usr/src/debug/php-8.1.1/Zend/zend_vm_execute.h:10137
10137 ce = CACHED_PTR(opline->op2.num);
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x7ffdc940e3a8:
(gdb) bt
#0 0x000055bbf04c0f25 in ZEND_NEW_SPEC_CONST_UNUSED_HANDLER () at /usr/src/debug/php-8.1.1/Zend/zend_vm_execute.h:10137
Cannot access memory at address 0x7ffdc940e3a8
(gdb) frame 0
#0 0x000055bbf04c0f25 in ZEND_NEW_SPEC_CONST_UNUSED_HANDLER () at /usr/src/debug/php-8.1.1/Zend/zend_vm_execute.h:10137
10137 ce = CACHED_PTR(opline->op2.num);
(gdb) info frame
Stack level 0, frame at 0x7ffdc940e3b0:
rip = 0x55bbf04c0f25 in ZEND_NEW_SPEC_CONST_UNUSED_HANDLER (/usr/src/debug/php-8.1.1/Zend/zend_vm_execute.h:10137); saved rip Cannot access memory at address 0x7ffdc940e3a8

this is the only available info in the core dump.

PHP Version

PHP 8.1.0 + 8.1.1

Operating System

CentOS 7

I'm afraid this is not actionable without further information, since you didn't provide a reproduce script, and the stack backtrace only shows 1 frame. Since you claim that happens randomly, providing a reproduce script may not be possible, but at the very least we need more info, such as whether OPcache is enabled, whether OPcache JIT is enabled (tracing or function), and in which environment (SAPI) this happens, and also whether that happens only occasionally (and recovers afterwards or not), or happens frequently. Also, try to run with the latest PHP-8.1 development version, where some PHP 8.1.1 bugs have been fixed.

it happens in php-fpm
randomly and frequent, cannot reproduce
there is nothing more in the backtrace, so its hard to find what function causes this
opcache settings:
opcache.enable = on;
opcache.enable_cli=1;
opcache.jit_buffer_size=1G;
opcache.validate_root = on;
opcache.enable_cli = on;
opcache.file_update_protection = 0;
opcache.revalidate_freq = 0;
opcache.validate_timestamps = 0;
opcache.interned_strings_buffer = 64;
opcache.max_accelerated_files = 16229;
opcache.memory_consumption = 4096;
opcache.fast_shutdown = 1;
opcache.log_verbosity_level = 2;
opcache.blacklist_filename = /etc/opcache-blacklist.txt;
opcache.force_restart_timeout = 1800;

Thanks for the further info! Does it also happen when JIT is disabled (i.e. opcache.jit_buffer_size=0)? If not, what happens if you use a smaller jit_buffer_size (1GB seems very much, maybe try 16M or 64M).

I disabled JIT for now, will update in a few days.

Okay, I'll change back to feeback status (the ticket will be kept open for 2 weeks).

I have SIGSEGV error on 8.3.1

So environment is dev on win11 x86-64, Docker with nginx and php-fpm 8.3.1 / wsl. php souce files mapped as volumes: - ./:/var/www/myproject/

php.ini:

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=134217728
opcache.jit=1235 ; I don't remember why not 1255 or 1205

I can't say how to reproduce the problem, but I have two ideas.

First. Is editing source files works correctly with JIT at all? In dev mode I edit php files and changes applied immediately. Must I disable JIT on dev environment when I use Docker?

And second, maybe this code reproduces SIGSEGV error:

trait foo
{
    protected static function load(MyClass $thisStatic, bool $condition): mixed
    {
        $query = Comment::where('use', '=', $thisStatic->id);

        if ($condition) {
            $query->where(function (mixed $query) use ($thisStatic): void {
                $query->where('timestamp', '>=', $thisStatic->start)
                      ->orWhere('created_at', '>=', date('Y-m-d H:i:s', $thisStatic->start));
            });
        } else {
            $query->where(function (mixed $query) use ($thisStatic, $divider): void {
                $query->whereBetween('timestamp', [$thisStatic->start, $thisStatic->end])
                      ->orWhere('timestamp', '>', $divider)
                      ->orWhereBetween('created_at', [date('Y-m-d H:i:s', $thisStatic->start), date('Y-m-d H:i:s', $thisStatic->end)])
                      ->orWhere('created_at', '>', date('Y-m-d H:i:s', $divider));
            });
        }

        return $query;
    }
}

It's Laravel Eloquent query builder. I could guess JIT engine may not correctly process Closure with arguments (argument is object passed to function).

However I'm not sure. It's hard to fix a non-reproducible problem.

I will try to rewrite query without Closure and with whereRaw instead. And use 1205 flags. I will write here if I find any information.

First. Is editing source files works correctly with JIT at all? In dev mode I edit php files and changes applied immediately. Must I disable JIT on dev environment when I use Docker?

JIT should work transparently, but of course "editing" may trigger some bugs that are not visible in usual production environments and that are even harder to reproduce.

In case you could provide a docker image with reproducible scenario, we would be able to understand and fix the problem.

Still happend with php 8.1.27 in offical php docker container.

There's nothing different, except add some extensions like this:

FROM php:8.1.27-fpm-alpine3.19

RUN echo "Start building.." \
    set -ex \
    && apk update \
    # install system base packages
    && apk add tzdata tini git openssh-server openssh-client rsync \
    # config timezone
    && ln -sf /usr/share/zoneinfo/${TIMEZONE} /etc/localtime \
    && echo "${TIMEZONE}" > /etc/timezone \
    # install php extensions
    && apk add pcre-dev $PHPIZE_DEPS gmp-dev zlib-dev libpng-dev \
    && docker-php-ext-install bcmath gmp calendar exif gd pdo_mysql sockets opcache \
    && pecl install -n redis && docker-php-ext-enable redis.so \
    # show php version and extensions
    && php -v \
    && php -m

CMD ["tini", "--", "entrypoint.sh"]

Running by tini, use exec to instead sh process.

entrypoint.sh:

#!/bin/sh -e
/usr/sbin/sshd -e -E /var/log/sshd.log &

cp /opt/crontab /etc/crontabs/www && chown root:root /etc/crontabs/www && chmod 600 /etc/crontabs/www &
crond -L /var/log/crond.log &

exec /usr/local/sbin/php-fpm

I ran into segmentation fault on 8.3.6 with my Symfony 7.x application with this config:

opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 16000
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1
opcache.enable=1
opcache.enable_cli=1
opcache.jit=1235
opcache.jit_buffer_size=256M

https://github.com/ovos/doctrine1 + php tests/run.php still segfaulting as of PHP 8.3.6.

As an experiment, did any of you compile PHP yourself? Or can you compile PHP yourself and try if it still segfaults? Not to use as a solution, but to test if this helps. Maybe it's the packaged PHP that is compiled to use architecture things that are not available on your local system (I'm just guessing here).

…

On Wed, 17 Apr 2024 at 16:06, Marcin G ***@***.***> wrote: https://github.com/ovos/doctrine1 + php tests/run.php still segfaulting as of PHP 8.3.6. — Reply to this email directly, view it on GitHub <#7817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMD2DTW3RJKDJL7VZI5L5LY5Z6VZAVCNFSM5KUJMA22U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWGEZTINZTGIZA> . You are receiving this because you commented.Message ID: ***@***.***>

@jorismak

Dear @jorismak I tried few times in the past, but never managed to compile PHP on Windows. I'm using the official package from
https://www.php.net/downloads.php
However we have also segfaults on servers (Linux), so we do not use JIT in production right now, because we have to restart FPM every time it happens.

On PHP 8.3.9 and Symfony 7.1.2, and with opcache.jit=1235, also segfault. Zend Engine v4.3.9, Zend OPcache v8.3.9.

@jorismak

@jorismak, @marcing, it is unlikely that the official Windows builds would use SIMD instructions which are not available, since they still use only SSE2 (on x64) and SSE (on x86). If you still want to do your own builds, see https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2. About a minimal build environment, see https://gist.github.com/cmb69/47b8c7fb392f5d79b245c74ac496632c.

As for the actual issue: these may actually be quite different issues, and it's almost impossible to fix; see #7817 (comment) on what might help.

To mitigate the crashes: try with tracing JIT disabled. If that doesn't work disable JIT altogether. If that still doesn't work, disable OPcache. Oh, and of course, if there are other "invasive" extensions (often zend_extensions) active, disable these, and see if it fixes (or at least improves) the situation. Info about what worked for you, and what not, wouldn't help us to fix the issue, but at least you would have stable system up and running.

opcache.jit=1205 has been stable for me so far.

Info about what worked for you, and what not, wouldn't help us to fix the issue, […]

This issue is really plaguing us. We were on 8.1.17, experiencing a really strange segfault within some Stripe-PHP code on one of our apps. I updated to 8.1.20, and that problem is fixed, but then I start getting segfaults on a totally different PHP on the same server. Had to revert that one to 7.3 😖 Changing JIT options doesn't seem to help with much

Unfortunately, I can't provide a repro but I have the following logs:

[33624850.446814] php-fpm8.1[5390]: segfault at 7fd70a5f1a38 ip 00007fed0cc18a6c sp 00007ffd2f24a3e0 error 4 in opcache.so[7fed0cc00000+df000] likely on CPU 7 (core 7, socket 0)

Yesterday there was an accident in my household, so I called the ambulance. They asked: "Where do you live?" I replied: "In my house, of course!" For some reason, they still didn't show up. ;)

What I want to say: please don't reply to this thread if your issue isn't even related to JIT (I already expect that those who reported JIT related segfaults may actually face quite different issues). Instead open a new ticket, and try to provide as much useful information as you can.

PHP 8.4 introduced and entirely new JIT implementation (https://wiki.php.net/rfc/jit-ir), and the previous PHP 8.0 JIT was removed.

Is this reproducible on PHP 8.4+?

Note that PHP 8.3 is no longer actively supported since Dec 2025 (https://www.php.net/supported-versions.php), so a bug specific would presumably be declined.

@Krinkle

@Krinkle Interesting, I had no idea, I basically disabled JIT and did not use it since then even on 8.5. Have to try it.

Navigation Menu

Repository navigation

JIT segmentation fault in PHP 8.1 #7817

Description

PHP Version

Operating System

191 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

JIT segmentation fault in PHP 8.1 #7817

Description

Description

PHP Version

Operating System

Activity

cmb69 commented on Dec 23, 2021

cappadaan commented on Dec 23, 2021

cmb69 commented on Dec 23, 2021

cappadaan commented on Dec 23, 2021

cmb69 commented on Dec 23, 2021

191 remaining items

adic3x commented on Feb 17, 2024

dstogov commented on Feb 19, 2024

xpader commented on Mar 29, 2024

palgalik commented on Apr 13, 2024

marcing commented on Apr 17, 2024

jorismak commented on Apr 18, 2024

marcing commented on Apr 18, 2024

klaussilveira commented on Jul 30, 2024

cmb69 commented on Jul 30, 2024

klaussilveira commented on Jul 30, 2024

cmb69 commented on Aug 19, 2024

daniellockyer commented on Aug 28, 2024

cmb69 commented on Aug 28, 2024

Krinkle commented on Oct 15, 2026

marcing commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions