You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
let window_data = windows.get_mut(&WindowId(xev.event)).unwrap()
It is caused by following events:
Create Window with EventsLoop
User creates some events (ex. mouse movement)
Window is drooped
Processing events on EventsLoop
Which creates situation where there are events waiting to be processed for a window that doesn't exist any more.
This is strictly minimal example. Real example creates new Window in step 3 and it doesn't matter if it's with old or new EventsLoop. Also moving 4. before 3. doesn't help because 2. can happen in between processing events and drooping Window.
I haven't looked if other platform implementations suffer from the same issue.
Quick and dirty fix would be to just ignore those events.
I am willing to implement this.
Relevant backtrace:
thread 'Updater[1]' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:20
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:380
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:396
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:610
5: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:571
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:521
7: rust_begin_unwind
at /checkout/src/libstd/panicking.rs:497
8: core::panicking::panic_fmt
at /checkout/src/libcore/panicking.rs:71
9: core::panicking::panic
at /checkout/src/libcore/panicking.rs:51
10: <core::option::Option<T>>::unwrap
at /checkout/src/libcore/macros.rs:22
11: winit::platform::platform::x11::EventsLoop::process_event
at /home/ktf/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/winit-0.7.5/src/platform/linux/x11/mod.rs:466
12: winit::platform::platform::x11::EventsLoop::poll_events
at /home/ktf/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/winit-0.7.5/src/platform/linux/x11/mod.rs:148
13: winit::platform::platform::EventsLoop::poll_events
at /home/ktf/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/winit-0.7.5/src/platform/linux/mod.rs:378
14: winit::EventsLoop::poll_events
at /home/ktf/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/winit-0.7.5/src/lib.rs:219
The text was updated successfully, but these errors were encountered:
Panic occurs in
unwrap()
for lines likelet window_data = windows.get_mut(&WindowId(xev.event)).unwrap()
It is caused by following events:
Window
withEventsLoop
Window
is droopedEventsLoop
Which creates situation where there are events waiting to be processed for a window that doesn't exist any more.
This is strictly minimal example. Real example creates new
Window
in step 3 and it doesn't matter if it's with old or newEventsLoop
. Also moving 4. before 3. doesn't help because 2. can happen in between processing events and droopingWindow
.I haven't looked if other platform implementations suffer from the same issue.
Quick and dirty fix would be to just ignore those events.
I am willing to implement this.
Relevant backtrace:
The text was updated successfully, but these errors were encountered: