winit: Crash in iOS when swiping up for the control center

On iOS 12.4.8 on my iPhone 6, using Bevy on winit, if I swipe up for the control center immediately after app load I get a crash. If I first touch the screen to fire some touch events before trying to open the control center, then there is no crash and everything works as normal.

I’m trying to reproduce this directly on winit, but haven’t been able to yet. Thought I’d post first anyway to see if this sounds familiar. I’ve googled various parts of the stack trace with no success.

It’s really bizarre because the crash is inside iOS libraries. Perhaps the gesture recogniser is registered on the winit-defined UIView / UIViewController and some interaction there is the problem. Unfortunately without any source to the stack trace I don’t know what this NSArray is. I suspect it’s just accumulating touch events as part of the “delay touch near edge of screen” logic.

Exception	NSException *	"*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil"	0x0000000282d89110

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001bd3239c0 libobjc.A.dylib`objc_exception_throw
    frame #1: 0x00000001be0c4bec CoreFoundation`_CFThrowFormattedException + 112
    frame #2: 0x00000001be0358ac CoreFoundation`-[__NSArrayM insertObject:atIndex:] + 1212
    frame #3: 0x00000001ea565868 UIKitCore`-[UIGestureRecognizer _delayTouch:forEvent:] + 216
    frame #4: 0x00000001ea5813c0 UIKitCore`-[_UISystemGestureGateGestureRecognizer _delayTouch:forEvent:] + 140
    frame #5: 0x00000001ea565a68 UIKitCore`-[UIGestureRecognizer _delayTouchesForEvent:inPhase:] + 220
    frame #6: 0x00000001ea565c98 UIKitCore`-[UIGestureRecognizer _delayTouchesForEventIfNeeded:] + 100
    frame #7: 0x00000001ea566a9c UIKitCore`-[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:] + 504
    frame #8: 0x00000001ea55ac78 UIKitCore`_UIGestureEnvironmentUpdate + 2180
    frame #9: 0x00000001ea55a3a8 UIKitCore`-[UIGestureEnvironment _deliverEvent:toGestureRecognizers:usingBlock:] + 384
    frame #10: 0x00000001ea55a188 UIKitCore`-[UIGestureEnvironment _updateForEvent:window:] + 204
    frame #11: 0x00000001ea9727d0 UIKitCore`-[UIWindow sendEvent:] + 3112
    frame #12: 0x00000001ea95285c UIKitCore`-[UIApplication sendEvent:] + 340
    frame #13: 0x00000001eaa189d4 UIKitCore`__dispatchPreprocessedEventFromEventQueue + 1768
    frame #14: 0x00000001eaa1b100 UIKitCore`__handleEventQueueInternal + 4828
    frame #15: 0x00000001eaa14330 UIKitCore`__handleHIDEventFetcherDrain + 152
    frame #16: 0x00000001be0dcf1c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
    frame #17: 0x00000001be0dce9c CoreFoundation`__CFRunLoopDoSource0 + 88
    frame #18: 0x00000001be0dc784 CoreFoundation`__CFRunLoopDoSources0 + 176
    frame #19: 0x00000001be0d76c0 CoreFoundation`__CFRunLoopRun + 1004
    frame #20: 0x00000001be0d6fb4 CoreFoundation`CFRunLoopRunSpecific + 436
    frame #21: 0x00000001c02d879c GraphicsServices`GSEventRunModal + 104
    frame #22: 0x00000001ea938c38 UIKitCore`UIApplicationMain + 212
  * frame #23: 0x0000000101dc0910 Callisto`cart_tmp_winit::platform_impl::platform::event_loop::EventLoop$LT$T$GT$::run::h2a3bed959aaaa659(self=EventLoop<()> @ 0x000000016ef50bb0, event_handler=closure-1 @ 0x000000016ef50bd0) at event_loop.rs:116:13
    frame #24: 0x0000000101de5b4c Callisto`cart_tmp_winit::event_loop::EventLoop$LT$T$GT$::run::h8c8ef82fc7ef7463(self=<unavailable>, event_handler=<unavailable>) at event_loop.rs:149:9
    frame #25: 0x0000000101de1724 Callisto`bevy_winit::run::h215a617795758f71(event_loop=<unavailable>, event_handler=<unavailable>) at lib.rs:43:5
    frame #26: 0x0000000101dd1d28 Callisto`bevy_winit::winit_runner::h90a304e554acabdc(app=App @ 0x000000016ef51c28) at lib.rs:244:9
    frame #27: 0x0000000101dda810 Callisto`core::ops::function::Fn::call::ha1caefc47bb26836((null)=0x0000000000000001, (null)=(bevy_app::app::App) @ 0x000000016ef51c28) at function.rs:70:5
    frame #28: 0x0000000102de6698 Callisto`_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..Fn$LT$A$GT$$GT$::call::h88bacb7a918cef10(self=0x000000016ef52628, args=(bevy_app::app::App) @ 0x000000016ef51f58) at boxed.rs:1056:9
    frame #29: 0x0000000102de8ca8 Callisto`bevy_app::app::App::run::h0e84ac1eed74c29a(self=App @ 0x000000016ef52ee8) at app.rs:80:9
    frame #30: 0x0000000102dcf734 Callisto`bevy_app::app_builder::AppBuilder::run::hed1780d15d7a0af0(self=0x000000016ef53558) at app_builder.rs:45:9
    frame #31: 0x0000000100f06808 Callisto`bevy_main at lib.rs:48:5
    frame #32: 0x0000000100eb3d5c Callisto`main at main.swift:17:1
    frame #33: 0x00000001bdb9a8e0 libdyld.dylib`start + 4

About this issue

Original URL
State: open
Created 4 years ago
Comments: 22 (16 by maintainers)

Commits related to this issue

disable window pre creation for ios (#5883) # Objective Fixes #5882 ## Solution Per https://github.com/rust-windowing/winit/issues/1705, the root cause is "UIWindow should be created inside... — committed to bevyengine/bevy by shuoli84 2 years ago
disable window pre creation for ios (#5883) # Objective Fixes #5882 ## Solution Per https://github.com/rust-windowing/winit/issues/1705, the root cause is "UIWindow should be created inside... — committed to nicopap/bevy by shuoli84 2 years ago
disable window pre creation for ios (#5883) # Objective Fixes #5882 ## Solution Per https://github.com/rust-windowing/winit/issues/1705, the root cause is "UIWindow should be created inside... — committed to james7132/bevy by shuoli84 2 years ago
disable window pre creation for ios (#5883) # Objective Fixes #5882 ## Solution Per https://github.com/rust-windowing/winit/issues/1705, the root cause is "UIWindow should be created inside... — committed to ItsDoot/bevy by shuoli84 2 years ago
disable window pre creation for ios (#5883) # Objective Fixes #5882 ## Solution Per https://github.com/rust-windowing/winit/issues/1705, the root cause is "UIWindow should be created inside... — committed to Subserial/bevy_winit_hook by shuoli84 2 years ago

Most upvoted comments

I’m not sure it’s technically possible to know if the main event loop is running on iOS, but if it is, we should definitely do this!

You can run event_loop in winit only once, so you sort of know. Just set a global AtomicBool from the run invokation.

kchibisov on Sep 5, 2022

Because it’s possible to create windows before StartCause::Init on other platforms, so there hasn’t been much incentive to change the API to something less ergonomic (but more correct) - it is something I’m quite annoyed with though, so I’ll probably write an issue and discuss a few solutions with the other maintainers at some point.

madsmtm on Sep 5, 2022

@madsmtm Thanks for the advice. From code here, seems the crate supports user create a new window instance and replace the one winit created. Seems a bit hacky in my mind… Do you know why it designed like this?

https://github.com/rust-windowing/winit/blob/0fca8b088d4c7fc3feb83567d284f169afc2f15c/src/platform_impl/ios/app_state.rs#L587-L604

shuoli84 on Sep 5, 2022

Wow nice work. I’ll try it when I get a chance. 😃

MichaelHills on Jan 27, 2021

#1843 Resolved this on my end. Would enjoy some other 👀

bigmstone on Jan 27, 2021