Could you email me the coredump? Might be an issue with PhpRedis itself, does switching to Predis resolve it?
Hi Till,
I actually already tested that, switching from PhpRedis to Predis via WP_REDIS_CLIENT did not resolve it. The crash reproduced identically with Predis active: same signal (SIGSEGV), same location, same timing pattern (crashes after ~700-1600+ seconds of sustained uptime, not on the initial request). Since Predis is a pure-PHP client with no compiled extension, this rules out a PhpRedis-specific bug — the crash is happening somewhere else.
Rather than the raw coredump (84MB compressed, and likely contains sensitive in-memory data like our Redis password and WP secret keys, so I’d rather not send it as-is), here’s the symbolic backtrace we extracted via coredumpctl + gdb with debug symbols installed:
0 ZEND_SEND_VAL_EX_SIMPLE_SPEC_CONST_HANDLER (execute_data=…, opline=…)
at Zend/zend_vm_execute.h:6227
This is core Zend Engine VM opcode-handling code — not extension-specific, and not something either PhpRedis or Predis directly controls. Given this, it looks more like a PHP 8.5.9 core memory-safety issue (heap corruption occurring earlier in the request lifecycle, only manifesting as a crash later when this specific opcode handler touches the corrupted region) that happens to get triggered when the object-cache drop-in is active — possibly due to something in how it interacts with PHP’s memory management during long-running FPM workers.
Environment for reference: PHP 8.5.9 (Plesk build), WordPress 7.0.3, Redis Object Cache plugin v2.8.0.
Happy to provide more detail (full backtrace with bt full, additional debug symbol output, sanitized memory regions if genuinely needed) — just wanted to flag the size/sensitivity concern before sending the raw dump itself. Let me know what would actually help most.
Thx
Br
Crissi
In that case we’d need to take a look at your fpm’s coredump to see whats going on, could be anything.
Update: resolved, and it’s not Redis Object Cache or PhpRedis — root cause is opcache.jit on PHP 8.5.9.
Crash reproduced identically with both PhpRedis and Predis, and the backtrace (ZEND_SEND_VAL_EX_SIMPLE_SPEC_CONST_HANDLER, Zend/zend_vm_execute.h) pointed to core VM opcode handling, not any Redis-specific code path. Set opcache.jit=disable — crash gone entirely. Confirmed stable across two production sites since, tens of thousands of cache hits (94%+ hit rate), zero segfaults, vs. reliably crashing within 10–30 min of FPM uptime before.
Matches a known pattern — PHP’s 8.5 changelog lists several recent tracing-JIT segfault fixes (GH-21746, GH-22004, etc.), so this looks like an unfixed JIT/Zend Engine interaction in 8.5.9, not a plugin issue. Flagging in case others hit the same thing — opcache.jit=disable is a clean workaround.
Thanks for the help narrowing it down.
