iOS: scrolling a UIStackView in a UIScrollView while mutating labels aborts with 'insertObject:atIndex:: object cannot be nil'

[proggeramlug]

Summary

Scrolling a UIScrollView-hosted UIStackView on a physical device while JS mutates its labels aborts the app:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
    reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
App terminated due to signal 6.

Requires human touch input. No automated probe reproduces it, which is why it has gone unseen — every headless run passes.

Where it throws

The backtrace is start → main → UIApplicationMain → CFRunLoop → CA transaction commit → UIView layout → UIStackView → throw. The exception lands in the layout pass at the end of a run-loop iteration, not inside any Perry callback. Something earlier leaves a nil in a UIKit array; it detonates at commit time.

Reproduction

Device: iPhone 16 Pro, iOS 26, Release build, --target ios.

PERRY_NO_AUTO_OPTIMIZE=1 perry run ios benchmarks/ios-ui/bench.ts --device <UDID>

Scroll the list continuously during the property-updates phase (50 labels, textSetString on each every frame) or add-remove (100 rows rebuilt 20x/sec). Crash lands within a few seconds. Without scrolling, the same build runs indefinitely.

PERRY_NO_AUTO_OPTIMIZE=1 is needed because perry-stdlib currently fails to build with --no-default-features — separate issue, see below.

Not caused by the frame-metrics work (#7754)

Established by four single-variable device bisects, each with a human scrolling:

arm	result
deferred view release	crashes
widget release disabled entirely	crashes
display link in NSDefaultRunLoopMode	crashes
display-link driver disabled, original NSTimer pump	crashes

The last arm is decisive: with #7754's driver removed and onFrame back on the pre-PR js_frame_pump_default() path, the abort still occurs. That PR's benchmark is simply the first workload that drives enough label mutation against a scrolled stack to expose it.

Hypotheses tested and falsified

• Deallocating views inside CoreAnimation's pre-commit phase — falsified; crashes with release deferred to a quiescent point.
• Releasing widget-table entries at all — falsified; crashes with release fully disabled. An isolation probe released ~323k widgets inline with no fault.
• Running JS during UITrackingRunLoopMode — falsified; crashes with the link in default mode, where JS is frozen during the drag.

Suggested next step

Symbolicate a full crash report (the raw frames above have no load address), and audit every path that can hand a view to a UIStackView arranged-subview array. add_child / add_child_at guard their handle lookups, so the nil likely enters via a UIKit-held reference to a view that went away, or via constraint bookkeeping in HEIGHT_CONSTRAINTS.

[proggeramlug]

Reproduction is narrower than first thought — it needs real touch

Two further device sessions refine the repro conditions.

1. It is probabilistic, not deterministic. A session with a person scrolling continuously through four full benchmark cycles (~400 s, all five phases each) did not crash, on the exact configuration that had aborted within a single phase earlier. So "scroll + mutate" is necessary but not sufficient; something narrower decides it — plausibly a specific gesture pattern, such as flicking during the rebuild burst, or deceleration overlapping a mutation.

2. Programmatic scrolling does not reproduce it. benchmarks/ios-ui/isolate_autoscroll.ts drives a sawtooth scrollviewSetOffset from the frame callback while mutating 50 labels every frame — the same two ingredients — and ran 13,200 frames clean.

setContentOffset runs neither UIScrollView's gesture recognizer nor UITrackingRunLoopMode, so the trigger is something only a genuine touch sequence provides. That rules out "scroll-driven layout while mutating" as a sufficient condition and points at the gesture/tracking machinery specifically.

Diagnostics now in place

perry-ui-ios installs NSSetUncaughtExceptionHandler, reporting the exception name, reason and [exception callStackSymbols]. NSException captures that stack at raise time and the ObjC runtime symbolicates it in-process, so the next occurrence yields named frames on stderr (streamed by devicectl --console) with no dSYM matching or offline .ips pass required.

That handler was live for the four-cycle session, so whenever this next fires interactively we should get the culprit immediately.

Suggested path to an automated repro

Synthetic touches are the missing piece, and the two in-tree options do not provide them:

• geisterhand's chaos mode invokes JS closures, not UITouch events, and perry_geisterhand_queue_scroll has no perry-ui-ios implementation at all.
• scrollviewSetOffset bypasses the gesture path, as measured above.

An XCUITest target driving XCUIElement.swipeUp() against the benchmark app would synthesize real touches through the system and could run the gesture in a loop until it aborts. That is the most likely route to a deterministic, human-free reproduction.