Inexplicable runtime error on M1-based macOS

[ChristianIvicevic]

I have been experimenting with winit and noticed that the following snippet has runtime errors on M1 chips:

use winit::dpi::LogicalSize;
use winit::event::{Event, WindowEvent};
use winit::event_loop::{ControlFlow, EventLoop};
use winit::platform::run_return::EventLoopExtRunReturn;
use winit::window::WindowBuilder;

struct Application {
    event_loop: EventLoop<()>,
}

impl Application {
    pub fn initialize() -> Self {
        let event_loop = Self::init_window();

        Self { event_loop }
    }

    fn init_window() -> EventLoop<()> {
        let event_loop = EventLoop::new();
        let _window = WindowBuilder::new()
            .with_title("Hello, World")
            .with_inner_size(LogicalSize::new(800, 480))
            .build(&event_loop)
            .unwrap();
        event_loop
    }

    fn main_loop(&mut self) {
        let mut should_close = false;
        loop {
            self.event_loop.run_return(|event, _, control_flow| {
                *control_flow = ControlFlow::Exit;

                match event {
                    Event::WindowEvent {
                        event: WindowEvent::CloseRequested,
                        ..
                    } => should_close = true,
                    _ => (),
                }
            });
            if should_close {
                return;
            }
        }
    }
}

fn main() {
    let mut app = Application::initialize();
    app.main_loop();
}

When starting the compiled app a stacktrace is displayed and the application is still running however without a window since the window that initially pops up vanishes right away:

2021-05-08 11:02:32.695543+0200 sample[81272:1716168] [General] *** -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array
2021-05-08 11:02:32.696191+0200 sample[81272:1716168] [General] (
	0   CoreFoundation                      0x00000001a124fdb8 __exceptionPreprocess + 240
	1   libobjc.A.dylib                     0x00000001a0f790a8 objc_exception_throw + 60
	2   CoreFoundation                      0x00000001a131abb4 -[__NSCFString characterAtIndex:].cold.1 + 0
	3   CoreFoundation                      0x00000001a116ea7c -[__NSArrayM objectAtIndex:] + 188
	4   sample                              0x00000001007177e0 _ZN64_$LT$$LP$A$C$$RP$$u20$as$u20$objc..message..MessageArguments$GT$6invoke17hfcfa89ce4923c108E + 104
	5   CoreFoundation                      0x00000001a11d0c60 __CFRunLoopDoObservers + 572
	6   CoreFoundation                      0x00000001a11d02c8 __CFRunLoopRun + 1052
	7   CoreFoundation                      0x00000001a11cf734 CFRunLoopRunSpecific + 600
	8   HIToolbox                           0x00000001a90cdb84 RunCurrentEventLoopInMode + 292
	9   HIToolbox                           0x00000001a90cd8f8 ReceiveNextEventCommon + 552
	10  HIToolbox                           0x00000001a90cd6b8 _BlockUntilNextEventMatchingListInModeWithFilter + 72
	11  AppKit                              0x00000001a39b94ec _DPSNextEvent + 836
	12  AppKit                              0x00000001a39b7e8c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1292
	13  AppKit                              0x00000001a39a9d18 -[NSApplication run] + 596
	14  sample                              0x00000001007763a8 _ZN60_$LT$$LP$$RP$$u20$as$u20$objc..message..MessageArguments$GT$6invoke17hacaea74fed85c1cdE + 72
)

I can confirm that the very same code works on Intel-based macOS just fine.

[ArturKovacs]

Are you using Rust 1.51? If you are, then try updating to 1.52 and see if the error still occurs. I believe this is related to #1925

[ChristianIvicevic]

Earlier today I updated to 1.52 and the issue still occurs. After some desparate trial and error I noticed the error occurs on ARM because the window object from init_window is not preserved and saved as a member variable like the event loop. Surprisingly enough this doesn't cause issues on Intel. Therefore I presume some special handling for ARM has to be implemented in platform-specific code.

[ArturKovacs]

Does this occur with winit 0.24?

[ChristianIvicevic]

Oh sorry for not mentioning the version I use, yes, it occurs with 0.24.

[ArturKovacs]

And just to clarify: Can you use the M1 machine to compile to x86_64 and run that without this issue?

[ChristianIvicevic]

I haven't compiled to x86_64 on the M1 machine but on a separate Intel machine with the same versions of compiler and winit crate. This is how I have confirmed that on Intel it seemed to work.

[ArturKovacs]

Could you try that? I believe you can install the x86_64 target using

rustup target add x86_64-apple-darwin

And then compile/run using

cargo run --target x86_64-apple-darwin

[ChristianIvicevic]

Your instructions were correct, a x86_64 compiled binary on M1 has the same issue.

[ArturKovacs]

Darn it. Thanks for all the info; unfortunately I don't have an M1 and I believe this is a duplicate of #1925 but I'm not sure.

[madsmtm]

@ChristianIvicevic it seems like a lot of debug information is stripped from that traceback, which makes it hard to know ? Don't know what you did exactly, but perhaps you could try without --release?

Anyhow, I think the code that could be causing this was removed in #2292, could I get you try the example again both before and after 4c39b31, and post the results?

[madsmtm]

I think that this was probably a duplicate of #1925, and is very likely fixed long ago.