Crash in iOS when swiping up for the control center #1705
Comments
francesca64
added
DS - ios
C - needs investigation
|
I was able to reproduce this using just the wgpu triangle example on winit. By just having this call to So seemingly wgpu somehow triggers the crash (and bevy uses wgpu so that probably explains my original crash). I don't really see what wgpu has to do with this though. |
|
On Bevy and iPhone 11 I can reproduce this crash by swiping in from any side of the screen. Specifically need to come in from the outside edge. It kind of sounds like this might be related to the |
|
@MichaelHills I am looking into this as well. I've noticed if you touch the screen prior to dragging in from the edges it will prevent the crash. I have put a bunch of traces into winit side of the UIApplication/View Controller, but haven't been able to determine much that route. None of my traces in the winit view class or the delegate are triggered before the crash (I was assuming I would see something on the touch handler). My best guess right now, and I'll reiterate it's only a guess, is there's some uninitialized array in the UIGestureRecognizer that somehow gets initialized when you provide a valid touch inside the app. I need to figure out some better way of troubleshooting this though. It all feels pretty opaque right now. I.E. I am not sure where exactly to put a break to begin stepping through because everything on the rust side is abstracted by |
|
This also seems related to #1613 — backtrace at a glance is the same. |
|
#1843 Resolved this on my end. Would enjoy some other 👀 |
|
Wow nice work. I'll try it when I get a chance. :) |
Bug and trouble shootingI've been debugging the crash bug for hours. It was reported by others and had a quick fix by setting ScreenEdge::ALL. Since the crash is reproducible, so I tried to tackle it down or at least find the root cause, I think I got something. UIGestureEnvironment is also a singleton which is inited and stored inside UIApplication. Also, it is stored in each UIGestureRecognizer instance if it is already created. And UIGestureRecognizer is created when we create UIWindow, which means at that time, the global didn't created, so all the recognizer with When ScreenEdge preference is 0, it triggers some logic of delay touch handling, and in that code path, it read the property as nil, which crashed when add into a nsarray. How to fix:UIWindow/UIView should be created by method on ApplicationDelegate, since UIApplicationMain will never return. OtherSome evidence (crashed is the bevy_ios_example. good is a normal created ios app): Crashed Good call stack |
|
Good full stack, we can see the window is created inside UIApplicationMain.
|
This sounds a lot like the same issue we have on macOS, which is documented in the bottom of the readme for now; can you try the suggested workaround (creating your window inside |
|
@madsmtm the window is created by winit, before it calls uiapplicationmain. I don’t think user has the chance to modify where to initialize the window in ios platform. |
|
Hmm, are you sure? I'm fairly certain you should be able to do something like this? use winit::{
event::{Event, StartCause, WindowEvent},
event_loop::EventLoop,
window::Window,
};
fn main() {
let event_loop = EventLoop::new();
let mut window = None;
event_loop.run(move |event, event_loop, control_flow| {
control_flow.set_wait();
match event {
Event::NewEvents(StartCause::Init) => {
window = Some(Window::new(&event_loop).unwrap());
}
Event::WindowEvent {
event: WindowEvent::CloseRequested,
window_id,
} if Some(window_id) == window.as_ref().map(|w| w.id()) => control_flow.set_exit(),
_ => (),
}
});
} |
|
@madsmtm I'm not sure, I just started read winit code the moment hit by the crash. But I see code in app_state, which implements EDIT: typo |
|
@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? winit/src/platform_impl/ios/app_state.rs Lines 587 to 604 in 0fca8b0 |
|
Because it's possible to create windows before |
|
We now suggest to create a window from inside The same applies for android, since it also should create from the Probably the right way is to |
|
@kchibisov Thanks, any link for the documentation? I scanned the code but didn't find anything. In readme, the window is created outside of the event loop. |
Oh right, yeah, that one.
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 |
# Objective Fixes #5882 ## Solution Per rust-windowing/winit#1705, the root cause is "UIWindow should be created inside UIApplicationMain". Currently, there are two places to create UIWindow, one is Plugin's build function, which is not inside UIApplicationMain. Just comment it out, and it works.
# Objective Fixes bevyengine#5882 ## Solution Per rust-windowing/winit#1705, the root cause is "UIWindow should be created inside UIApplicationMain". Currently, there are two places to create UIWindow, one is Plugin's build function, which is not inside UIApplicationMain. Just comment it out, and it works.
# Objective Fixes bevyengine#5882 ## Solution Per rust-windowing/winit#1705, the root cause is "UIWindow should be created inside UIApplicationMain". Currently, there are two places to create UIWindow, one is Plugin's build function, which is not inside UIApplicationMain. Just comment it out, and it works.
# Objective Fixes bevyengine#5882 ## Solution Per rust-windowing/winit#1705, the root cause is "UIWindow should be created inside UIApplicationMain". Currently, there are two places to create UIWindow, one is Plugin's build function, which is not inside UIApplicationMain. Just comment it out, and it works.
|
Sorry if this is not appropriate to ask here, but does anyone have a sort of minimal example of an iOS winit app? I'm not getting any touch events firing at all. I do see window resize events/resume events/etc, so I assume everything else is functioning. |
Did you get any further with this? I'd also appreciate an example or guide (and for Android) |
|
@dominictobias the android is dead simple though. You could look at the https://github.com/rust-windowing/glutin/blob/master/glutin_examples/examples/android.rs . And that's the only thing you'd need, the rest is the same as on any other OS. Not familiar with how to setup iOS example. |
Ah nice thanks. I didn't try yet I can prob figure iOS out then |
# Objective Fixes #5882 ## Solution Per rust-windowing/winit#1705, the root cause is "UIWindow should be created inside UIApplicationMain". Currently, there are two places to create UIWindow, one is Plugin's build function, which is not inside UIApplicationMain. Just comment it out, and it works.
|
Aand I intend to update our iOS setup instructions in #3873, so I'll close this now (feel free to comment on that PR instead regarding iOS setup instructions). |
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.
The text was updated successfully, but these errors were encountered: