What
Writing a static property from inside a closure and reading it back yields a garbage integer that differs between runs. That is a read of uninitialised memory, not a logic error.
|
|
| Zend 8.2.32 |
12 |
| AOT |
-6341068275337658368 — and not stable between runs |
Why this one is separated from the other static-property bugs
The rest of the static-property group produces wrong-but-deterministic values. This one does not, and that difference matters:
- an unstable value will not stay caught by a compliance case — it can pass by luck
- reading uninitialised memory is a different class of defect from a wrong store, with different consequences (it can expose whatever was previously on the stack/heap)
It should be fixed on its own terms rather than folded into a general "static properties are broken" ticket.
Other static-property divergences (same sweep, likely separate causes)
| probe |
Zend |
AOT |
| static array property default |
3 |
0 |
| static property increment in a method |
2 |
1 |
| child class sharing parent's static property |
42 |
1 |
| static array property returned by value |
1 |
99 (aliases instead of copying) |
??= to a static property |
int(7) |
NULL (not stored) |
function-static array element write across calls |
12 |
11 |
& reference to a static property |
99 |
Notice: Only variables should be assigned by reference |
Plus three aborts (exit 134): array-callable to a static method, string-callable to a static method, and a static method called on an instance.
Provenance
Probe-reported by a differential hunt; not yet independently reproduced. The instability is itself the evidence for the uninitialised-memory reading — a deterministic wrong value would suggest a wrong store instead.
Prerequisite
Not measurable before #31894 (merged). script/aot-smoke.sh must read 8/8 before working this.
Done when
- the closure-write/read case returns
12 and is stable across repeated runs
- a compliance case asserts the value, and ideally runs the binary more than once so instability cannot pass by luck
Context: docs/roadmap/AOT-CORRECTNESS-PLAN.md (group 3).
What
Writing a static property from inside a closure and reading it back yields a garbage integer that differs between runs. That is a read of uninitialised memory, not a logic error.
12-6341068275337658368— and not stable between runsWhy this one is separated from the other static-property bugs
The rest of the static-property group produces wrong-but-deterministic values. This one does not, and that difference matters:
It should be fixed on its own terms rather than folded into a general "static properties are broken" ticket.
Other static-property divergences (same sweep, likely separate causes)
3021421199(aliases instead of copying)??=to a static propertyint(7)NULL(not stored)staticarray element write across calls1211&reference to a static property99Notice: Only variables should be assigned by referencePlus three aborts (exit 134): array-callable to a static method, string-callable to a static method, and a static method called on an instance.
Provenance
Probe-reported by a differential hunt; not yet independently reproduced. The instability is itself the evidence for the uninitialised-memory reading — a deterministic wrong value would suggest a wrong store instead.
Prerequisite
Not measurable before #31894 (merged).
script/aot-smoke.shmust read 8/8 before working this.Done when
12and is stable across repeated runsContext:
docs/roadmap/AOT-CORRECTNESS-PLAN.md(group 3).