Environment: Foundation SDK 1.0.0 hosted simulator, macOS 26.6.1 (arm64).
The simulator's gui-server aborts on a synthetic mouse-down. A Rust panic
raised inside winit's WinitView::mouse_down cannot unwind across the
Objective-C boundary, so it becomes panic_cannot_unwind → abort() and takes
the whole simulator down.
Exception Type: EXC_CRASH (SIGABRT)
Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Application Specific Information: abort() called
Thread 0 Crashed:: main Dispatch queue: com.apple.main-thread
2 libsystem_c.dylib abort + 148
5 gui-server std::panicking::panic_with_hook + 796
9 gui-server core::panicking::panic_nounwind_fmt + 40
11 gui-server core::panicking::panic_cannot_unwind + 24
12 gui-server winit::platform_impl::macos::view::WinitView::mouse_down + 396
13 AppKit forwardMethod + 252
14 AppKit -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3696
...
20 AppKit -[NSApplication run] + 408
22 gui-server gui_server::display::emulator::window::run_window + 544
The crash report attributes the triggering event to our automation tool:
"voucherInfos" : [{"originatorName":"simtap","thread_id":17160935}]
How we hit it
We drive the simulator for UI tests by posting CoreGraphics mouse events
(CGEventPost) at the device window — the same approach we have used since SDK
0.4.0, because AppleScript clicks do not reach the emulator's canvas. Under
1.0.0 the server aborts intermittently on those clicks. Real hand-driven
clicking is far slower and we have not seen it there, so the trigger looks
timing- or coordinate-related rather than "synthetic events" as such.
The practical cost is that a crash mid-test looks exactly like the app ignoring
input: the window stays up (the app process outlives the server), later taps do
nothing, and nothing in the app's log explains it. We spent a while blaming our
own app before the crash report surfaced.
What would help
- Don't let a panic in the mouse handler abort the process. Catching it at
the mouse_down boundary (or making that path panic-free) would leave the
emulator usable.
- If the panic has a known cause — e.g. an event whose coordinates fall
outside the emulated screen, or one arriving before the display is ready —
validating it at entry would fix the root rather than the symptom.
Happy to supply the full crash report or a reproduction script if useful.
Environment: Foundation SDK 1.0.0 hosted simulator, macOS 26.6.1 (arm64).
The simulator's
gui-serveraborts on a synthetic mouse-down. A Rust panicraised inside winit's
WinitView::mouse_downcannot unwind across theObjective-C boundary, so it becomes
panic_cannot_unwind→abort()and takesthe whole simulator down.
The crash report attributes the triggering event to our automation tool:
How we hit it
We drive the simulator for UI tests by posting CoreGraphics mouse events
(
CGEventPost) at the device window — the same approach we have used since SDK0.4.0, because AppleScript clicks do not reach the emulator's canvas. Under
1.0.0 the server aborts intermittently on those clicks. Real hand-driven
clicking is far slower and we have not seen it there, so the trigger looks
timing- or coordinate-related rather than "synthetic events" as such.
The practical cost is that a crash mid-test looks exactly like the app ignoring
input: the window stays up (the app process outlives the server), later taps do
nothing, and nothing in the app's log explains it. We spent a while blaming our
own app before the crash report surfaced.
What would help
the
mouse_downboundary (or making that path panic-free) would leave theemulator usable.
outside the emulated screen, or one arriving before the display is ready —
validating it at entry would fix the root rather than the symptom.
Happy to supply the full crash report or a reproduction script if useful.