Repository navigation
Closed as not planned
Labels
Description
Description
PHP config: https://paste.daniil.it/config
gdb backtrace:
(gdb) backtrace
#0 0x0000561fa234fd48 in ZEND_INIT_NS_FCALL_BY_NAME_SPEC_CONST_HANDLER () at ./Zend/zend_vm_execute.h:56188
#1 execute_ex (ex=0x7fbe32a15630) at ./Zend/zend_vm_execute.h:56188
#2 0x0000561fa2354701 in zend_execute (op_array=0x7fbe32a7e000, return_value=0x0) at ./Zend/zend_vm_execute.h:60396
#3 0x0000561fa22e1e55 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at ./Zend/zend.c:1827
#4 0x0000561fa227d3fa in php_execute_script (primary_file=<optimized out>) at ./main/main.c:2542
#5 0x0000561fa23cb50a in do_cli (argc=9, argv=0x561fa37bd170) at ./sapi/cli/php_cli.c:964
#6 0x0000561fa210dc5b in main (argc=9, argv=0x561fa37bd170) at ./sapi/cli/php_cli.c:1333
zbacktrace:
(gdb) zbacktrace
[0x7fbe32a15570] Zoon\Cache\Provider\Redis->getRedisClient() /zoon/zoon/vendor/zoon/cache/src/Provider/Redis.php:69
[0x7fbe32a15400] Zoon\Cache\Provider\Redis->getInternal("system_load_v2:z216:local_load", "") /zoon/zoon/vendor/zoon/cache/src/Provider/Redis.php:151
[0x7fbe32a15320] Zoon\Cache\Provider\CacheProvider->get("system_load_v2:z216:local_load", "") /zoon/zoon/vendor/zoon/cache/src/Provider/CacheProvider.php:144
// more stuff
Redis.php:69 is weird, because it points to the array_key_exists in closeRedisConnection, not the getRedisClient function mentioned in the backtrace, which by the way have the following code
private function getRedisClient(): RedisClient {
$pid = getmypid();
$serverKey = "{$pid}:{$this->params['host']}:{$this->params['port']}";
if (!array_key_exists($serverKey, self::$instances)) {
self::$instances[$serverKey] = new RedisClient(
$this->params['host'],
$this->params['port'],
$this->params['database'],
$this->params['connect_timeout'],
$this->params['max_reconnect'] ?? 0,
);
}
return self::$instances[$serverKey];
}
private function closeRedisConnection() {
$pid = getmypid();
$serverKey = "{$pid}:{$this->params['host']}:{$this->params['port']}";
if (array_key_exists($serverKey, self::$instances)) {
try {
self::$instances[$serverKey]->close();
} catch (\Throwable $e) {
trigger_error($e->getMessage(), E_USER_WARNING);
} finally {
unset(self::$instances[$serverKey]);
}
}
}
Feel free to tag me if further inspection of the coredump is neeed.
ref: compressed_coredump-php.113283.1688702030
PHP Version
PHP 8.2.7
Operating System
Ubuntu 20.04, ondrej repos
Activity
ndossche commentedon Jul 10, 2023
Does this also happen if you disable preloading?
How often is this reproducible? Does it always reproduce and is it always in the same location?
danog commentedon Jul 10, 2023
Both preloading and JIT are disabled again for now (and in this case especially, since it's a CLI coredump).
I've yet to work through the full backlog of ~16 coredumps that were reported over the weekend, but for now this is the only occurrence of this specific issue.
danog commentedon Jul 10, 2023
Spoke too soon, already found another coredump with the same zbacktrace and backtrace.
I got permission to DM both coredumps if needed.
ref: compressed_coredump-php.113283.1688702030
Now I wonder if the issue is caused by the pcntl_fork in Thread.php...
kamil-tekiela commentedon Nov 7, 2026
I am closing this issue because it is not actionable in the current state. We need an ASAN log or a reproducer. However, it's highly probable that this was caused by one the enabled third-party extensions and not PHP core. Since this was raised over 3 years ago and for PHP 8.2, I believe we should not worry too much about it now. However, if you can still easily reproduce it with a supported version, please raise a new GH issue with a reproducer or ASAN.