A core dump occurs frequently when PHP is loaded using HTTP. The core dump error log is AH00051: child pid 6663 exit signal Segmentation falult(11).

[zqtop]

Description

After the GDB and PHPDebug are enabled, the system reports the zend_object_handlers.c file based on the core information. An exception is reported: No such file or directory. The error function is as follows:

ZEND_API zval *zend_std_read_dimension(zend_object *object, zval *offset, int type, zval *rv) /* {{{ */
{
    zend_class_entry *ce = object->ce;
    zval tmp_offset;

    if (EXPECTED(zend_class_implements_interface(ce, zend_ce_arrayaccess) != 0)) {
        if (offset == NULL) {
            /* [] construct */
            ZVAL_NULL(&tmp_offset);
        } else {
            ZVAL_COPY_DEREF(&tmp_offset, offset);
        }

        GC_ADDREF(object);
        if (type == BP_VAR_IS) {
            zend_call_method_with_1_params(object, ce, NULL, "offsetexists", rv, &tmp_offset);
            if (UNEXPECTED(Z_ISUNDEF_P(rv))) {
                OBJ_RELEASE(object);
                zval_ptr_dtor(&tmp_offset);
                return NULL;
            }
            if (!i_zend_is_true(rv)) {
                OBJ_RELEASE(object);
                zval_ptr_dtor(&tmp_offset);
                zval_ptr_dtor(rv);
                return &EG(uninitialized_zval);
            }
            zval_ptr_dtor(rv);
        }

        zend_call_method_with_1_params(object, ce, NULL, "offsetget", rv, &tmp_offset);

        OBJ_RELEASE(object);
        zval_ptr_dtor(&tmp_offset);

        if (UNEXPECTED(Z_TYPE_P(rv) == IS_UNDEF)) {
            if (UNEXPECTED(!EG(exception))) {
                zend_throw_error(NULL, "Undefined offset for object of type %s used as array", ZSTR_VAL(ce->name));
            }
            return NULL;
        }
        return rv;
    } else {
        zend_bad_array_access(ce);
        return NULL;
    }
}

The following figure shows the GDB debugging error.

Unsupported JIT protocol version 3054402800 in descriptor (expected 1)
Core was generated by `/home/ivs_omu_portal/httpd/bin/httpd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  zend_std_read_dimension (object=0x100000000, offset=0xffff51ff94e0, type=65535, rv=0x0)
    at /var/lib/docker/home/workspace/IVS_V1000_micloud/workcode/Micro_3rd_opensource/open_source/portalBuild/arm1620/code/php/Zend/zend_object_handlers.c:934
934     /var/lib/docker/home/workspace/IVS_V1000_micloud/workcode/Micro_3rd_opensource/open_source/portalBuild/arm1620/code/php/Zend/zend_object_handlers.c: No such file or directory.
[Current thread is 1 (LWP 3997154)]
(gdb) bt
#0  zend_std_read_dimension (object=0x100000000, offset=0xffff51ff94e0, type=65535, rv=0x0)
    at /var/lib/docker/home/workspace/IVS_V1000_micloud/workcode/Micro_3rd_opensource/open_source/portalBuild/arm1620/code/php/Zend/zend_object_handlers.c:934
#1  <signal handler called>
#2  0x0000000000000000 in ?? ()
#3  0x0000000000000013 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) bt
#0  zend_std_read_dimension (object=0x100000000, offset=0xffff51ff94e0, type=65535, rv=0x0)
    at /var/lib/docker/home/workspace/IVS_V1000_micloud/workcode/Micro_3rd_opensource/open_source/portalBuild/arm1620/code/php/Zend/zend_object_handlers.c:934
#1  <signal handler called>
#2  0x0000000000000000 in ?? ()
#3  0x0000000000000013 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

PHP Version

PHP-8.1.8

Operating System

Eulter

[cmb69]

Does this happen with OPcache JIT being enabled? Which settings (especially, opcache.jit). Can you also reproduce without OPcache?

[zqtop]

I checked my server configuration carefully and did not enable the Opace module. I disabled the Opace module when compiling PHP with the following configuration: ./configure --prefix=$BASEDIR/compiled-php \ --with-apxs2=/home/ivs_omu_portal/httpd/bin/apxs \ --with-libxml-dir=$BASEDIR/libraries-all \ --with-expat \ --enable-opcache=no \ --disable-phar \ --enable-sockets \ --with-zlib \ --with-jpeg \ --with-freetype=$BASEDIR/libraries-all \ --enable-gd \ --with-iconv=$BASEDIR/libraries-all \ --with-curl \ --with-openssl \ --with-config-file-path=/home/ivs_omu_portal/httpd/conf \ --enable-mbstring \ --disable-mbregex \ --enable-memory-limit \ --without-sqlite3 \ --without-pdo_sqlite Excluding this factor, AH00051: child pid 6663 exit signal Segmentation falult(11) still occurs on our servers.

[zqtop]

This problem does not occur every time. After the server runs PHP 8.1.8 for a period of time, this problem occurs and a coredump occurs.

[cmb69]

Are you possibly switching Fibers in a signal handler?

[zqtop]

I don't particularly understand what software you're talking about.

[cmb69]

It's about the PHP script/application which causes these segfaults. As of PHP 8.1.0, there is a new feature called Fibers. Switching these from within a signal handler installed via pcntl_signal() is not properly supported.

[zqtop]

When I was using PHP 8.1.7, the core information was Core was genreated by /home/ivs_omu_portal/httpd/bin/httpd. Program terminated with signal SIGBUS ,Bus error. I'm not quite sure whether this error is what you say

[zqtop]

When PHP debugging is not enabled, I check the stack information of the GDB. The following information is displayed: Program terminated with signal SIGSEGV,Segmentation fault