enigo raises SIGTRAP error when used in conjunction with Bevy

[waffleattack]

Bevy version

0.10.1 The release number or commit hash of the version you're using.

[Optional] Relevant system information

M1 Macbook Air, Running Macos Ventura 13.3.1

What you did

While attempting to make a macro recorder app that uses engo to simulate key presses and bevy as a display, encountered SIGTRAP when trying to simulate keypress.

To Reproduce:

fn main() {
    thread::spawn(|| {
        thread::sleep(Duration::from_millis(5000));
        let mut engio = Enigo::new();
        engio.key_click(Key::Layout('u'));
    });
    App::new()
        .insert_resource(ClearColor(Color::NONE))
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                transparent: true,
                decorations: true,
                window_level: WindowLevel::AlwaysOnTop,
                resizable: true,
                focused: false,
                resolution: WindowResolution::new(500.0, 50.0),
                #[cfg(target_os = "macos")]
                composite_alpha_mode: CompositeAlphaMode::PostMultiplied,
                ..default()
            }),
            ..default()
        })).run();
}

What went wrong

App crashed and printed this error to console

Process finished with exit code 133 (interrupted by signal 5: SIGTRAP)

[alice-i-cecile]

Can you reproduce this upstream in winit? This is much more likely to originate there.

[waffleattack]

ah you are correct, it is a problem in winit, apologies for wasting time

[alice-i-cecile]

Ha, it's handy to have these issues on our tracker even if we're blocked. That helps other users search for the problem and get information about the fix.

In this case, we're blocked on https://github.com/rust-windowing/winit/issues/2829.

[mockersf]

The crash is coming from enigo, and it seems it doesn't happen if you use key_sequence instead of key_click

the backtrace:

  * frame #0: libdispatch.dylib`_dispatch_assert_queue_fail + 120
    frame #1: libdispatch.dylib`dispatch_assert_queue + 196
    frame #2: HIToolbox`islGetInputSourceListWithAdditions + 160
    frame #3: HIToolbox`isValidateInputSourceRef + 92
    frame #4: HIToolbox`TSMGetInputSourceProperty + 44
    frame #5: test-program`enigo::macos::macos_impl::Enigo::create_string_for_key::h21b6f38a0c76f603(self=0x0000000170006c08, keycode=0, modifier=256) at macos_impl.rs:525:13
    frame #6: test-program`enigo::macos::macos_impl::Enigo::keycode_to_string::h41091ef853685829(self=0x0000000170006c08, keycode=0, modifier=256) at macos_impl.rs:507:25
    frame #7: test-program`enigo::macos::macos_impl::Enigo::get_layoutdependent_keycode::h76d8dbd3af7f8413(self=0x0000000170006c08, string=(data_ptr = "u", length = 1)) at macos_impl.rs:478:39
    frame #8: test-program`enigo::macos::macos_impl::Enigo::key_to_keycode::hc8a9c438152f0ae1(self=0x0000000170006c08, key=Key @ 0x0000000170006b00) at macos_impl.rs:467:31
    frame #9: test-program`_$LT$enigo..macos..macos_impl..Enigo$u20$as$u20$enigo..KeyboardControllable$GT$::key_click::h707ac1422d8b97b3(self=0x0000000170006c08, key=Key @ 0x0000000170006ba8) at macos_impl.rs:361:23

I'm guessing that to translate the key layout to an actual string they are trying to lock a keyboard resource that's already locked by winit

[kchibisov]

Given that you brought to winit a code touching macOS API off the main thread(the example posted for us did that), ensure that you dispatch all the calls working with AppKit from the main thread with libdispatch help, because it seems like you've hit that assert in apple stuff.