AOT: `gc_collect_cycles()` segfaults with 2,000 cyclic objects (Zend collects 1,998) — and 200k objects also trigger a false "Undefined variable $a" warning (lib/JIT/Builtin/GcCollectCyclesRuntime.php, ext/standard/GcCollectCyclesRegistryJitHelper.php)

[PurHur]

Category

Regression: · runtime crash · child of #36188

Problem

Verified on master 4eed6a2785 in the pinned image (build/audit/v_gc1.php):

<?php class N { public $o; }
for ($r = 0; $r < 2; $r++) {
  for ($i = 0; $i < 1000; $i++) { $a = new N; $b = new N; $a->o = $b; $b->o = $a; }
  echo gc_collect_cycles(), "\n";
}

	Zend	AOT
output	1998 / 2000	Segmentation fault (rc 139), no output

With 100,000 pairs per round (build/audit/p_gc.php) the binary additionally prints PHP Warning: Undefined variable $a in … on line 1 before crashing — $a is assigned on every iteration, so the warning is the module-global undefined-variable flag (#36190) misfiring on a {main} loop variable. The 65,536-object hard cap in GcCollectCyclesRuntime::MAX_OBJECTS (#36195) is a separate defect; 2,000 objects are far below it, so this crash is in the mark/sweep itself (phpc_gc_collect_cycles_impl) or in the property-count/phpc_gc_prop_counts bookkeeping for objects whose only property is another object.

gc_collect_cycles() is called by frameworks, test runners and long-running workers; any AOT binary doing so with live cycles dies.

php-src reference

• Zend/zend_gc.c zend_gc_collect_cycles — mark roots grey, scan, collect white; refcounts of the objects being freed are decremented through zend_objects_store_del, never read after free.

PHP implementation target

• Reproduce under PHP_COMPILER_LLVM_ASSERT=1 and gdb -batch -ex run -ex bt (recipe in docs/AGENT-HANDOVER-2026-08-17.md); the audit log shows the crash is deterministic.
• Fix the collector for the cycle-of-two shape, then run the probe at 1k / 10k / 100k pairs (the last one also exercises the Runtime: fixed static arenas give hello-world a 70 MB .bss and the cycle collector silently stops tracking objects after 65,536 (lib/JIT/Builtin/GcCollectCyclesRuntime.php, lib/JIT/Builtin/StreamGlobalsJit.php) #36195 cap — coordinate).
• Add both probes to test/differential/cases/ (gc_collect_cycles return value must match Zend) and a gc_status() parity case.

Repro

./script/docker-exec.sh -- bash -lc 'source script/php-env.sh && php bin/compile.php -o build/gc1 build/audit/v_gc1.php && ./build/gc1; echo rc=$?; php build/audit/v_gc1.php'

Done when

• The 1k-pair probe prints 1998 / 2000 under AOT; the 100k probe prints no warning and matches Zend's counts (with Runtime: fixed static arenas give hello-world a 70 MB .bss and the cycle collector silently stops tracking objects after 65,536 (lib/JIT/Builtin/GcCollectCyclesRuntime.php, lib/JIT/Builtin/StreamGlobalsJit.php) #36195) or at least does not crash
• script/differential-sweep.sh --aot --repeat 10 unchanged plus the new cases green

[PurHur]

claim: implementer-worker-lane-c — starting this run (lane overflow: #36143–#36148 closed; lane C tie-break)

[PurHur]

PR opened with partial fix (registry mismatch diagnosis + PHP free/collect routing). Repro still segfaults rc=139 — phpc_gc_free_object may still resolve to LLVM kernel body on early-return re-entry. See PR for verify output and next step.

[PurHur]

claim: compile-trust-automation — starting this run (lane overflow: #36143–#36148 closed; gates green)

[PurHur]

claim: implementer-worker-lane-a — continuing PR #36268 (lane A tie-break #36245 % 3 == 0)

[PurHur]

claim: cursor-agent — starting this run (lane C tie-break #36245 % 3 == 2)

[PurHur]

Investigation (compile-trust-automation)

Pillar 1 gates on master: aot-smoke 9/9, north-star5-verify-fast OK, apply-patches.sh OK. #36143–#36148 closed — claimed #36245.

Repro matrix (pinned Docker image, HEAD)

program	Zend	AOT
single 2-node cycle, gc_collect_cycles()	0	0 (OK)
two sequential pairs + reassignment (unrolled loop)	2	0 (silent wrong count, no crash)
for/while loop building 2 pairs then gc_collect_cycles()	2	SIGSEGV (139)
issue body (2×1000 pairs, two rounds)	1998/2000	SIGSEGV

Finding: crash is not generic multi-object GC — it requires loop-carried \$a/\$b phis plus cyclic property stores before gc_collect_cycles(). Unrolled reassignment leaves the same orphan+live object pattern but does not crash (still returns 0 vs Zend 2).

Attempted fixes (not sufficient for merge)

1. phpc_gc_unregister LLVM swap: also swap G_MARKED/G_INBOUND alongside registry swap-remove (AOT: gc_collect_cycles() segfaults with 2,000 cyclic objects (Zend collects 1,998) — and 200k objects also trigger a false "Undefined variable $a" warning (lib/JIT/Builtin/GcCollectCyclesRuntime.php, ext/standard/GcCollectCyclesRegistryJitHelper.php) #36245 theory).
2. Standalone sweep freeBb: pre-free marked/inbound swap in JitGcCollectCyclesStandaloneKernel.
3. PHP GcCollectCyclesNativeScanJitHelper sweep: align marked/inbound on registry tail-move.

None changed the loop crash or the silent 0 on unrolled case — suggests primary defect may be loop lowering corrupting object property/refcount state visible to the LLVM GC scan, not only sweep index bookkeeping.

Routing standalone through PHP registry (usesPhpRegistry=true) breaks all standalone AOT (even echo hello segfaults) — reverted.

Next step

• Debug loop phi + instance property store (\$a->o = \$b in back-edge) vs registry/refcount seen by standaloneLoadObjectRefcount at gc_collect_cycles time.
• Add test/differential/cases/ repro for loop+cycle (must not regress VM 142/142).
• Keep LLVM kernel path; do not enable PHP registry for standalone without fixing standalone init/link.

WIP branch agent/issue-36245-gc-collect-cycles-segfault has the swap bookkeeping patches if useful as a base — not merge-ready.

[PurHur]

Worker lane A — run update (not merge-ready)

Pushed to PR #36268 (bedc48ca29).

Findings

1. PHP-registry routing (prior PR approach) mixes LLVM phpc_gc_register with PHP collect/free on helper-cache early-return — segfault. Forcing full PHP implement hits LLVM block is already sealed.
2. LLVM phpc_gc_unregister swap-remove was not moving G_MARKED/G_INBOUND entries — sweep mark arrays desync.
3. Nested standalone_registry_count bridge reads phpc_gc_count=0 at runtime even when objects exist (global linkage); snapshot path cannot work without fixing that.

This commit

• Swap G_MARKED/G_INBOUND during phpc_gc_unregister swap-remove
• GcCollectCyclesNativeScanJitHelper: two-phase $toFree[] sweep
• Revert usesPhpRegistry() user-script routing (stay on LLVM kernel)
• Repro scripts under test/repro/gc_*_36245.php

Verify

./script/phpunit.sh --filter GcCollectCyclesAotCycleTest  # 2/2 OK
# Docker:
php bin/compile.php -o /tmp/p test/repro/gc_collect_cycles_pairs_n_36245.php && /tmp/p
# → 0 (Zend 2), rc=0 — no segfault on single pair (progress)
php bin/compile.php -o /tmp/gc1 test/repro/gc_collect_cycles_cycle_pairs_36245.php && /tmp/gc1
# → still rc=139 on 1000×2

Next

• LLVM kernel two-phase sweep (malloc pointer list) OR fix inbound/root marking (orphan pairs return 0)
• Do not merge until pairs_n → 2 and full repro → 1998/2000 without segfault

[PurHur]

PR #36271 (not merged — repro still red on AOT ≥2 cyclic pairs)

Landed in branch

• LLVM unregister swap-remove copies G_MARKED + G_INBOUND
• Native-scan sweep: $toFree list + GcCollectCyclesNativeFreeJitHelper::freeRegistryObject() (PHP-registry slot clear)
• UserScriptAotEnv latch for NestedJIT

Verify

./script/phpunit.sh --filter GcCollectCyclesAotCycleTest  → OK (2 tests)
./script/aot-smoke.sh → 9 passed
php bin/jit.php … 2 pairs → 2 (embed path OK)
AOT 2 pairs → segfault rc=139 (Zend: 2)

Next step

Route user-script standalone collect through unified PHP-registry GC bundle (single NestedJIT TU, skipHelperRuntimeCache) or ASAN/gdb the LLVM standalone phpc_gc_collect_cycles_impl sweep — marked/inbound carry alone is insufficient.