Growing a Mixed-promoted array in a loop then iterating+consuming it corrupts the heap

[mirchaemanuel]

Summary

Growing an array that has been promoted to mixed-element storage (array<mixed>) across loop iterations, then iterating it and consuming each value, corrupts the heap: the program prints wrong/empty output or segfaults. No enum, closure, or object is involved — a plain intval() / (int) cast / += on the foreach value is enough.

Verified on

main (macOS ARM64, default EIR backend). No #349/#449 changes involved — reproduces on a clean main build.

Minimal reproduction

<?php
$vals = [];
for ($i = 0; $i < 2; $i++) {
    $vals[] = 1;      // int
    $vals[] = 2.0;    // float → promotes the array to array<mixed>, then keeps growing
}
$sum = 0;
foreach ($vals as $v) {
    $sum += intval($v);
}
echo $sum, "\n";

Actual

Prints an empty line (and sometimes segfaults, exit 139) — the result is nondeterministic across runs but consistently wrong. Deterministically wrong across repeated runs in practice.

Expected

6

(matches PHP: 1 + 2 + 1 + 2)

Notes / scope

• The trigger is a mixed-promoted array that is grown further after promotion inside a loop, then iterated and consumed. A single-shot build ($a = []; $a[] = 1; $a[] = 2.0; then iterate) works; a literal [1, 2.0, 1, 2.0] works. The corruption appears when the promoted array is repeatedly appended-to across for iterations and later iterated with per-element consumption (intval($v), (int)$v, $sum += $v).
• The symptom is heap free-list corruption (wrong/empty output, or SIGSEGV in __rt_heap_alloc), so it is an ownership/refcount problem in the array_to_mixed promotion + subsequent array_push + foreach value lifetime, not a codegen arithmetic bug.
• Surfaced while reviewing the enum from(mixed) work (Backed-enum from()/tryFrom() reject a Mixed argument (untyped param / foreach value) at compile time #449): an int-backed Enum::from($v) over such an array crashes, but the crash reproduces identically with intval($v) and no enum, confirming it is orthogonal to enums.

[mirchaemanuel]

Fixed in #475. The diagnosis took a turn worth documenting.

Bisection first

The original repro suggested an ownership bug in the foreach consume. Bisecting it disproved that: the minimal failing program needs no foreach at all —

$vals = [];
for ($i = 0; $i < 2; $i++) { $vals[] = 1; $vals[] = 2.0; }
echo $vals[2];   // SIGSEGV; PHP prints 1

count($vals) is right, indices 0/1/3 read fine; only element 2 — the first append of the second iteration — is poison. An empty-body foreach (pure acquire/release traffic over every element) is clean; any value-read of slot 2 crashes. And a literal [1, 2.0] init with the same loop appends works. So: not ownership, not the iterator — the array itself holds a corrupt element, written on iteration 2.

Root cause: single-pass loop typing vs the back edge

Both the type checker and the EIR lowering process a loop body once, with the types in force on the way in:

• $vals[] = 1 is typed/lowered against array<never> → emitted as a raw scalar array_push;
• $vals[] = 2.0 sees array<int> + float → emits the array_to_mixed promotion (boxed cells).

The back edge brings the promoted array<mixed> around, but nothing re-visits site A: from iteration 2 it writes an unboxed i64 into boxed-cell storage. Reading that slot dereferences 1 as a Mixed cell pointer → SIGSEGV. The int+string flavour "survives" reads (the raw payload happens to be a valid pointer) and instead corrupts values silently and leaks — same defect, softer symptom.

Fix shape

The two passes are parallel single-pass analyses (the checker's TypeEnv, and ir_lower's own local_types), so fixing only the checker wouldn't change what the emitter does. Instead of a full fixed-point re-check, the fix adds a small shared prescan (types/checker/loop_widening.rs): walk the loop body's statements, collect its $name[] = value push sites, and compute the element-type join per target local. Only the representation-changing transition matters — a join to mixed. For those locals:

• the checker widens the TypeEnv entry before checking the body (all four loop kinds; for foreach, after the value/key bindings so a push of the loop variable joins with its real element type);
• ir_lower widens local_types the same way and materializes the promotion once, before the loop (array_to_mixed is in-place, same pointer), so every push site inside the body boxes its value.

Same-type pushes and never → T growth keep their exact current lowering — on those paths the generated IR is byte-identical to main (verified). Loops that previously re-promoted at the push site each iteration now hoist a single conversion out of the loop.

Verified

Repro family (2–5 iterations, while/do-while/nested loops, push under if/try, foreach value-var pushes, string+float flavour) all match PHP with a clean --heap-debug; adversarial shapes (iterate-and-push snapshot semantics, break before the promoting site ever runs, COW copies between iterations, continue skipping a site) verified against PHP. Six regression tests in tests/codegen/array_basics.rs.

One pre-existing, unrelated gap surfaced while probing loop shapes: the parser rejects an array push (and comma-separated expressions) in the for update clause — filed as #476.