Korean input causes panic

[dbluhm]

Which operating system does the issue occur on? Fedora 27, using cargo run from a fresh git clone If on linux, are you using X11 or Wayland? On Wayland but used WAYLAND_DISPLAY=

Hopefully this gif makes it clear what happens. On completion of a block in Korean, the terminal crashes with the error shown above.

Any thoughts? Thanks for your help!

[Aaron1011]

Could you paste the exact characters you used here?

[dbluhm]

Any Korean symbol seemed to do it. The other day at a different computer, it worked just fine, albeit spaces are inserted before completing the symbol instead of after but that's a different problem. I see that same behaviour in st. I unfortunately can't verify what commit I was on when it worked. But I can verify that 03f9e0c doesn't work. What I typed in though was "한". Copying and pasting works for whatever reason.

[dmeijboom]

Can you paste a backtrace? You can do this using: WAYLAND_DISPLAY= RUST_BACKTRACE=1 cargo run

[dbluhm]

thread 'main' panicked at 'attempt to subtract with overflow', /home/dbluhm/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/linux/x11/mod.rs:415:35
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:68
             at libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: rust_begin_unwind
             at libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   9: core::panicking::panic
             at libcore/panicking.rs:51
  10: winit::platform::platform::x11::EventsLoop::process_event
             at /home/dbluhm/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/linux/x11/mod.rs:415
  11: winit::platform::platform::x11::EventsLoop::run_forever
             at /home/dbluhm/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/linux/x11/mod.rs:186
  12: winit::platform::platform::EventsLoop::run_forever
             at /home/dbluhm/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/linux/mod.rs:405
  13: winit::EventsLoop::run_forever
             at /home/dbluhm/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/lib.rs:231
  14: alacritty::window::Window::wait_events
             at ./src/window.rs:283
  15: <alacritty::event::Processor<N>>::process_events
             at ./src/event.rs:376
  16: alacritty::run
             at src/main.rs:179
  17: alacritty::main
             at src/main.rs:62
  18: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  19: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  20: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  21: std::rt::lang_start_internal
             at libstd/panicking.rs:458
             at libstd/panic.rs:358
             at libstd/rt.rs:58
  22: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  23: main
  24: __libc_start_main
  25: _start

[dmeijboom]

Thanks. It looks like it's an upstream issue, see: https://github.com/tomaka/winit/issues/366

[chrisduerr]

The upstream issue has been fixed.