Repository navigation
for (var k …) inside a function hangs forever when a closure in the body captures k #11052
Description
Activity
A/B: this predates #11053, and it's a spin, not a park.
Same fixtures built with both compilers (
PERRY_NO_CACHE=1, Linux x86_64), each run for 3 s and then sampled:arm compiler closure never called ( v3)read = () => k(v1)h += read()(v)A = main f5cfbff88sha256 1f1ef6c5fee7hang hang hang B = #11053 sha256 bb654007a784hang hang hang Every hung process was in state R at 100% CPU: 1 thread, no children, and 100 CPU ticks in the sampled second. So it's a busy loop, not a wait: the loop condition never becomes false. The first suspect is the counter's storage (the
k++and thek < ntest on different copies oncekis boxed for the closure), not the event loop or a lock.(B's binary was built from the pre-amend commit
4d1f97c3c;git diff 4d1f97c3c e8c3b8947touches only three campaign tooling files, no code.)- added 4 commits that reference this issue
on Sep 23, 2026
A
for (var k = ...; k < n; k++)loop inside a function never terminates when any closure in the loop body capturesk. The closure doesn't have to be called.Reproduced on main
f5cfbff88(v0.5.1638), Linux x86_64,PERRY_NO_CACHE=1:timeout 5, rc=124)5read = () => kassigned each iteration, called after the loop5 5n: number5 5h += read()inside the loop10 5 5var kdeclared at module level, same loop in a function5 5✅5 5So the trigger is a function-scoped
varinduction variable that a closure captures. The loop uses the generic boxed counter in its IR (found while working on loop-counter representation). Presumably the increment and thek < ntest are not reading and writing the same storage: one goes to the closure box and the other to a local copy. That is inferred, not verified.Found while validating an unrelated loop-counter change, which hangs identically on both arms: the bug predates that change and the change does not admit this case.
https://claude.ai/code/session_01EQdCw7BN4AAnn2hAbNXg33