Winit: `multithreaded` example crashes on key press on macOS

Created on 10 Jun 2019  路  5Comments  路  Source: rust-windowing/winit

Pressing any keys when running the multithreaded example from eventloop-2.0 will crash on macOS.

Sometimes it produces a segmentation fault and other times it produces a panic.

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
stack backtrace:
   0:        0x1096a2b83 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hf2949dcf16da83bd
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:        0x10969eca2 - std::sys_common::backtrace::_print::h4b87ed6ba0cd5304
                               at src/libstd/sys_common/backtrace.rs:71
   2:        0x1096a1b26 - std::panicking::default_hook::{{closure}}::hde39fed432870543
                               at src/libstd/sys_common/backtrace.rs:59
                               at src/libstd/panicking.rs:197
   3:        0x1096a18cf - std::panicking::default_hook::hfce8820d41dbdcbf
                               at src/libstd/panicking.rs:211
   4:        0x1096a229f - <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get::h7aefec6ee3a0deaf
                               at src/libstd/panicking.rs:474
   5:        0x1096a1dcc - std::panicking::continue_panic_fmt::h4d668741ea600293
                               at src/libstd/panicking.rs:381
   6:        0x1096a1cb8 - std::panicking::try::do_call::h1252fc9a2ff235eb
                               at src/libstd/panicking.rs:308
   7:        0x1096b6ae1 - <T as core::any::Any>::type_id::h2f1dfe6f5ac846ab
                               at src/libcore/panicking.rs:85
   8:        0x1096b6a26 - <T as core::any::Any>::type_id::h2f1dfe6f5ac846ab
                               at src/libcore/panicking.rs:49
   9:        0x1096a497b - panic_unwind::dwarf::eh::read_encoded_pointer::hf5b0123b85857914
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libcore/macros.rs:12
                               at src/libpanic_unwind/gcc.rs:91
                               at src/libpanic_unwind/lib.rs:90
  10:        0x10942da14 - std::panicking::try::hfa151a0f5c16c8bc
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panicking.rs:272
  11:        0x10943bd8f - std::panic::catch_unwind::hda7deb41f7a68c84
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panic.rs:388
  12:        0x10943babd - std::thread::Builder::spawn_unchecked::{{closure}}::h7b8f56d6f4049637
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/thread/mod.rs:469
  13:        0x10944b8f4 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h4224278819b07abf
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libcore/ops/function.rs:231
  14:        0x109697f4d - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hf8766009c029bc09
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/liballoc/boxed.rs:702
  15:        0x1096a3f2d - std::sys::unix::thread::Thread::new::thread_start::hfdef4649a42cf26c
                               at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/liballoc/boxed.rs:702
                               at src/libstd/sys_common/thread.rs:14
                               at src/libstd/sys/unix/thread.rs:80
  16:     0x7fff619eb304 - _pthread_body
  17:     0x7fff619ee26e - _pthread_start
fatal runtime error: failed to initiate panic, error 5
[1]    71246 abort      RUST_BACKTRACE=full cargo run --example multithreaded
macOS high bug

Most helpful comment

Thank you for the stack trace @anderejd! It looks like this comes down to the set_title call in the example that is invoked on key press. The NSWindow setTitle function does not appear to be thread-safe, so wrapping this with the grand central dispatch used elsewhere in the backend fixes the issue. It looks like the set_maximized function isn't handling this correctly either.. I can take a look at putting together a pull request for all this today.

All 5 comments

This is quite... unfortunate. Sadly we lack a maintainer for macOS, so.... this might be here a while. :/

With panic = "abort" I get something useful:

2019-06-12 21:45:19.244 multithreaded[7791:713704] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff51253cfd __exceptionPreprocess + 256
    1   libobjc.A.dylib                     0x00007fff7b8f9a17 objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff5126d85d -[NSException raise] + 9
    3   AppKit                              0x00007fff4e8a27ae -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 317
    4   AppKit                              0x00007fff4e8c4462 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 98
    5   AppKit                              0x00007fff4e8eecce -[NSTitledFrame _titleDidChange] + 217
    6   AppKit                              0x00007fff4e8ee77c -[NSTitledFrame setTitle:] + 713
    7   AppKit                              0x00007fff4e8ee404 -[NSThemeFrame setTitle:] + 50
    8   AppKit                              0x00007fff4e8b214e -[NSWindow _dosetTitle:andDefeatWrap:] + 210
    9   multithreaded                       0x00000001044d7a6a _ZN64_$LT$$LP$A$C$$RP$$u20$as$u20$objc..message..MessageArguments$GT$6invoke17h59efddcf499dd6c2E + 74
    10  multithreaded                       0x00000001044e2f05 _ZN4objc7message8platform15send_unverified17h230a62f6b14860f3E + 85
    11  multithreaded                       0x00000001044dc20b _ZN77_$LT$$BP$mut$u20$objc..runtime..Object$u20$as$u20$cocoa..appkit..NSWindow$GT$9setTitle_17h1ef2b00ac298428aE + 299
    12  multithreaded                       0x00000001044c3091 _ZN5winit13platform_impl8platform6window13UnownedWindow9set_title17h87b3bd7a4cd666bbE + 129
    13  multithreaded                       0x000000010445d212 _ZN5winit6window6Window9set_title17h122efdece5354c52E + 50
    14  multithreaded                       0x0000000104469c79 _ZN13multithreaded4main28_$u7b$$u7b$closure$u7d$$u7d$17h2431bc6b833d533cE + 441
    15  multithreaded                       0x000000010445d6a0 _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hfcd7895e5ffd68c0E + 48
    16  multithreaded                       0x000000010447a850 _ZN3std6thread7Builder15spawn_unchecked28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17hc87415c20beb5db6E + 48
    17  multithreaded                       0x0000000104473d20 _ZN101_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$9call_once17hc3fc8cc7f654e382E + 48
    18  multithreaded                       0x000000010448053d _ZN3std9panicking3try7do_call17h962d9ea7fc13fd60E + 93
    19  multithreaded                       0x00000001046b1e7c __rust_maybe_catch_panic + 12
    20  multithreaded                       0x0000000104480445 _ZN3std9panicking3try17h2070da90a3ca2bbbE + 117
    21  multithreaded                       0x0000000104473d60 _ZN3std5panic12catch_unwind17h51524f57c146c281E + 48
    22  multithreaded                       0x000000010447a69e _ZN3std6thread7Builder15spawn_unchecked28_$u7b$$u7b$closure$u7d$$u7d$17hf069d6064b2e2985E + 302
    23  multithreaded                       0x0000000104465a85 _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h63506fde6130681fE + 21
    24  multithreaded                       0x00000001046a573e _ZN83_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$9call_once17hf8766009c029bc09E + 62
    25  multithreaded                       0x00000001046b171e _ZN3std3sys4unix6thread6Thread3new12thread_start17hfdef4649a42cf26cE + 142
    26  libsystem_pthread.dylib             0x00007fff7d2bb2eb _pthread_body + 126
    27  libsystem_pthread.dylib             0x00007fff7d2be249 _pthread_start + 66
    28  libsystem_pthread.dylib             0x00007fff7d2ba40d thread_start + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

__Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'__

It seems like winit needs to ensure somehow that the main thread is the only one capable of doing these system calls. I don't have more time for this right now, maybe in a week or two. Good luck!

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-SW1

Thread-Unsafe Classes

The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time. Check the class documentation for additional details.
[...]
NSWindow and all of its descendants. For more information, see Window Restrictions.

Thank you for the stack trace @anderejd! It looks like this comes down to the set_title call in the example that is invoked on key press. The NSWindow setTitle function does not appear to be thread-safe, so wrapping this with the grand central dispatch used elsewhere in the backend fixes the issue. It looks like the set_maximized function isn't handling this correctly either.. I can take a look at putting together a pull request for all this today.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

francesca64 picture francesca64  路  4Comments

rukai picture rukai  路  4Comments

dhardy picture dhardy  路  3Comments

felixrabe picture felixrabe  路  3Comments

hobogenized picture hobogenized  路  3Comments