Wezterm: SIGSEGV after showing ssh auth prompt

Created on 11 Aug 2020  路  3Comments  路  Source: wez/wezterm

Describe the bug

When starting wezterm connect <host> it crashes very early - just after creating a window.

Environment (please complete the following information):

  • OS: Linux X!!
  • Version: wezterm 20200718-095447-d2315640-1-g28836224

To Reproduce

wezterm connect <host> to a host running wezterm start --front-end MuxServer.

Steps to reproduce the behavior.

Please include as much information as possible that can help to reproduce and
understand the issue; some pointers and suggestions are included here in this
template. You are empowered to include more or less information than is asked
for here!

Configuration

local wezterm = require('wezterm')

local username = "jsgf"

return {
        scrollback_lines = 10000,
        enable_scroll_bar = true,

        enable_wayland = false, -- Wayland way too janky
        window_padding = {
                left = 7,
                right = 15, -- also scrollbar width
                top = 2,
                bottom = 2,
        },
        font = wezterm.font("Hasklig"),
}

Expected behavior

Not crash

Screenshots

If applicable, add screenshots to help explain your problem. Screenshots are most
appropriate for rendering issues.

Additional context

If the server isn't running it falls back to ssh, which pops the window up for login details OK - except that its transparent (ie, the alpha channel doesn't look initialized).

Crash happens when running optimized build:

Thread 1 "wezterm" received signal SIGSEGV, Segmentation fault.
0x000055555576bbe0 in wezterm::frontend::gui::termwindow::TermWindow::render_screen_line_opengl ()

(gdb) bt
#0  0x000055555576bbe0 in wezterm::frontend::gui::termwindow::TermWindow::render_screen_line_opengl ()
#1  0x0000555555768005 in wezterm::frontend::gui::termwindow::TermWindow::paint_tab_opengl ()
#2  0x000055555575f2aa in <wezterm::frontend::gui::termwindow::TermWindow as window::WindowCallbacks>::paint_opengl ()
#3  0x0000555555cdc7df in window::os::x11::window::XWindowInner::paint ()
#4  0x0000555555cc25f7 in <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop ()
#5  0x000055555581d876 in wezterm::run ()
#6  0x0000555555815851 in wezterm::main ()
#7  0x00005555556de033 in std::rt::lang_start::{{closure}} ()
#8  0x0000555556134a08 in std::rt::lang_start_internal::{{closure}} () at src/libstd/rt.rs:52
#9  std::panicking::try::do_call () at src/libstd/panicking.rs:297
#10 std::panicking::try () at src/libstd/panicking.rs:274
#11 std::panic::catch_unwind () at src/libstd/panic.rs:394
#12 std::rt::lang_start_internal () at src/libstd/rt.rs:51
#13 0x00005555558239a2 in main ()

Running a debug build shows:

 2020-08-11T00:22:23.915Z ERROR wezterm::mux > read_pty EOF: tab_id 0
 2020-08-11T00:22:24.490Z ERROR wezterm::mux > removing window 0
thread 'main' panicked at 'assertion failed: backend.is_current()', /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:646:17
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc/boxed.rs:1090
  11: wezterm::notify_on_panic::{{closure}}
             at src/main.rs:709
  12: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:490
  13: std::panicking::begin_panic
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:410
  14: <glium::context::Context as glium::ContextExt>::make_current
             at /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:646
  15: glium::context::Context::is_context_lost
             at /home/jsgf/.cargo/registry/src/github.com-1ecc6299db9ec823/glium-0.27.0/src/context/mod.rs:420
  16: window::os::x11::window::XWindowInner::paint
             at window/src/os/x11/window.rs:155
  17: window::os::x11::connection::XConnection::do_paint
             at window/src/os/x11/connection.rs:432
  18: <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop
             at window/src/os/x11/connection.rs:203
  19: <window::os::x_and_wayland::Connection as window::connection::ConnectionOps>::run_message_loop
             at window/src/os/x_and_wayland.rs:103
  20: <wezterm::frontend::gui::GuiFrontEnd as wezterm::frontend::FrontEnd>::run_forever
             at src/frontend/gui/mod.rs:71
  21: wezterm::run_mux_client
             at src/main.rs:504
  22: wezterm::run
             at src/main.rs:904
  23: wezterm::main
             at src/main.rs:725
  24: std::rt::lang_start::{{closure}}
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  25: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  26: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  27: std::panicking::try
             at src/libstd/panicking.rs:274
  28: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  29: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  30: std::rt::lang_start
             at /home/jsgf/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  31: main
  32: __libc_start_main
  33: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread panicked while processing panic. aborting.
Illegal instruction (core dumped)
bug

All 3 comments

except that its transparent (ie, the alpha channel doesn't look initialized).

https://github.com/wez/wezterm/commit/4605244af79648f7c26edf795b3e6f277352ad1f fixes that bit

I can reproduce this. What's happening here is that opengl is being torn down by the drop impl when the ssh auth window is closed, which leaves it in a broken state just in time for the window you want to use to trip over it :-/

Here's a terrible workaround:

diff --git a/window/src/egl.rs b/window/src/egl.rs
index cbc88977..7db835f4 100644
--- a/window/src/egl.rs
+++ b/window/src/egl.rs
@@ -52,6 +52,7 @@ pub struct GlState {

 impl Drop for GlState {
     fn drop(&mut self) {
+        /*
         unsafe {
             self.egl.egl.MakeCurrent(
                 self.display,
@@ -63,6 +64,7 @@ impl Drop for GlState {
             self.egl.egl.DestroyContext(self.display, self.context);
             self.egl.egl.Terminate(self.display);
         }
+        */
     }
 }

The proper fix is to separate out the display and library state from the window state and then record the display bits in the connection and the window bits in the individual windows.

Was this page helpful?
0 / 5 - 0 ratings