PHP 8.6 rc4 zts segfault -> turbo extension requires rebuild for 8.6rc4-zts? #15504

Bug report

php-zts vendor/bin/phpstan analyse
Segmentation fault

php-zts -v

PHP 8.6.0RC4 (cli) (built: Oct 21 2026 17:30:25) (ZTS gcc 16.2.0 x86_64)
Copyright © The PHP Group and Contributors
Built by Marc Henderkes <pkg@henderkes.com> #StandWithUkraine
Zend Engine v4.6.0RC4, Copyright © Zend by Perforce
    with Zend OPcache v8.6.0RC4, Copyright ©, by Zend by Perforce

vendor/bin/phpstan --version
PHPStan - PHP Static Analysis Tool 2.3.1

-> If I understand it correctly, only a rebuild of the turbo extension is required for 8.6rc4-zts

from ds 4.1 flash:

Ran exactly that, with the trace captured to a file:

strace -ff -o /tmp/opencode/phpstan-strace php-zts vendor/bin/phpstan analyse

Exit code 139. One trace file: /tmp/opencode/phpstan-strace.80782.

What the trace shows

1. Line 4664 – PHPStan re-executes itself (pcntl_exec from TurboProcessRestarter) with the bundled turbo extension added:

   execve("/usr/bin/php-zts", [..., "-d", "extension=.../turbo-ext/linux-gnu-x86_64/phpstan_turbo-8.6-zts.so", ...])
   

2. Lines 5208/5222 – it opens phpstan_turbo-8.6-zts.so and phpstan_turbo_core.so.
3. Lines ~9760–9827 – it reads turbo-shadowed-classes.json, then turbo-class-map.php from the phar. That is the last work it does.
4. Line 9828 – immediate crash:

   --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xfffffffffc8ffaf8} ---
   

   PHP's signal handler resets SIGSEGV to SIG_DFL, re-raises it via tgkill, and the process dies.

There are no missing files, permission errors, or loader failures before the crash. It dies right after TurboExtensionEnabler::activateIfCompatible() loads the class map, i.e. inside the native extension.

Root cause

gdb confirms the crash is in the extension, not your code:

#0 zend_hash_add
#1 phpstan_turbo-8.6-zts.so
#2 Runtime::activateShadowing()

The bundled ZTS binary has a stale compile-time EG(class_table) offset:

• Extension uses: -0x9e0
• PHP 8.6.0RC4 expects: -0xbd0 + 0x1d0 = -0xa00

That is a 32-byte mismatch. The NTS build accesses 0x1d0(%rbx) instead, which is why NTS works. PHPStan 2.3.1 (latest as of today) was built against an earlier 8.6 header snapshot; the module API number did not change, so PHP loads it anyway and then crashes in zend_hash_add.

Verified workarounds

For the last one:

mv vendor/phpstan/phpstan/turbo-ext/linux-gnu-x86_64/phpstan_turbo-8.6-zts.so \
   vendor/phpstan/phpstan/turbo-ext/linux-gnu-x86_64/phpstan_turbo-8.6-zts.so.off
php-zts vendor/bin/phpstan analyse
# restore later:
mv vendor/phpstan/phpstan/turbo-ext/linux-gnu-x86_64/phpstan_turbo-8.6-zts.so.off \
   vendor/phpstan/phpstan/turbo-ext/linux-gnu-x86_64/phpstan_turbo-8.6-zts.so

PHPSTAN_TURBO=0 does not work in 2.3.1 — I tested it, and the extension is still loaded.

Recommendation: use php vendor/bin/phpstan analyse for static analysis. If you need php-zts for the DuckDB tests, keep the turbo .so disabled until PHPStan ships a ZTS binary rebuilt against PHP 8.6.0RC4/final. This is worth reporting upstream to phpstan/turbo-ext with the trace and gdb output; it affects any extension built before the RC4 struct change. No project files were changed.

Code snippet that reproduces the problem

No response

Expected output

Note: Using configuration file /home/tb/code/laravel-duckdb/phpstan.neon.dist.
10/10 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
[OK] No errors

Did PHPStan help you today? Did it make you happy in any way?

No response