Compiler SIGSEGV: ++/-- lowering crashes on null locals and under the FunctionStatic phpunit filter

[PurHur]

Summary

Two related pre-existing segfaults (rc=139) in the compiler process itself, both surviving #16564 (verified identical with and without it):

1. ./phpc build on:

<?php
$x = null; echo ++$x, "|"; $y = null; $y--; var_dump($y);

crashes the compiler (no diagnostics, core dump). VM output is correct (1|NULL).

2. vendor/bin/phpunit --filter 'FunctionStatic|TypedFunctionStatic' segfaults mid-suite in the pinned container (after the static_closure_init cases).

Environment

php-compiler:22.04-dev (PHP 8.2.31 + LLVM 9 FFI).

Notes

• Likely the same underlying crash in ++/-- lowering via FFI (both paths exercise incdec on null/boxed operands).
• Blocks trusting the FunctionStatic phpunit battery as a gate; targeted per-test runs pass.

Done when

• Both repros exit cleanly (build succeeds or fails with a diagnostic; phpunit filter completes)
• AOT output for repro 1 matches VM (1|NULL)

🤖 Generated with Claude Code

[PurHur]

claim: cursor-agent-lane-c — starting this run

[PurHur]

claim: PHP Runtime → PHP — starting this run

[PurHur]

claim: worker-lane-c — starting this run (AOT compile SIGSEGV repro confirmed: exit 139 on bin/compile.php)

[PurHur]

Merged via #16573

Fix: Standalone AOT (LOAD_TYPE_STANDALONE) again uses StringVarDumpJit / StringPrintRJit LLVM monoliths. Nested JIT compile of VarDumpJitHelper was pulling VmVarDump and SIGSEGV-ing LLVM 9 during phpc build. Embed/self-host path still uses php-in-PHP VarDumpJitHelper bridge.

Verified:

• php bin/compile.php test/repro/maintainer_gap_incdec_null_aot_compile.php → exit 0 (was 139)
• ./phpc build same repro → exit 0 (was 139)
• VM repro prints 1|NULL
• VarDumpRuntimeShrinkTest + StringPrintRVarDumpRuntimeStandaloneTest + NullIncDecTest green

Follow-up: FunctionStaticJitCompileTest / phpunit --filter FunctionStatic still SIGSEGV on master (pre-existing; function-static LLVM init, not var_dump).

[PurHur]

WIP blocked: concurrent VarDumpJitHelper edits on harness cause intermittent LLVM verifier failures. Pivoting to #16557; will resume formatVariableValue bridge after stash settles.

[PurHur]

Merged via #16579

Root cause: nested JIT compile of VarDumpJitHelper::dumpValue produced LLVM symbols ending in dumpvalue, colliding with LLVMDumpValue (SIGSEGV during AOT compile when scripts call var_dump()).

Fix: rename to formatVariableValue, guard llvmInternalName, nested VM\Variable → __value__* ABI; removed interim StringVarDumpJit monolith.

Verification:

php bin/compile.php -o /tmp/inc test/fixtures/aot/compile-only/incdec_null_vardump.php  # exit 0
php bin/vm.php test/fixtures/aot/compile-only/incdec_null_vardump.php  # 1|NULL
vendor/bin/phpunit --filter IncDecNullVarDumpAotCompileTest  # OK

[PurHur]

New data from two full ci-fast battery runs (11,956 and 12,003 tests):

Both runs died in the same region (~test 6,000 / 50%, shortly after the stdlib array-pointer tests, inside the attr_/asymmetric_ compliance-case cluster). Kernel log shows the crash is a null-pointer segfault inside libLLVM-9.so.1 at the identical offset every time:

php[1423066]: segfault at 0 ip ...422 error 4 in libLLVM-9.so.1[cbb422,...]  (02:51)
php[1636110]: segfault at 0 ip ...422 error 4 in libLLVM-9.so.1[cbb422,...]  (04:15)
php[1636420]: segfault at 0 ip ...422 error 4 in libLLVM-9.so.1[cbb422,...]  (04:15)

Same offset cbb422 across independent processes ⇒ one specific LLVM API misuse (null argument into an LLVM call), not memory corruption randomness. After the segfaults the phpunit parent eventually hung (no output from 07:00, killed 07:56).

Repro guidance for whoever picks this up: the crash children are JIT compile subprocesses spawned while the battery is between the stdlib array-pointer tests and the attribute/asymmetric compliance cases — running that compliance slice alone under dmesg -w should isolate the case file in minutes. Resolving this (plus the loop-test timeout, #15906) is what stands between the now-green gate layers (#16508) and a full green ci-fast.