Wezterm: linux iris driver segfault on first run

[katef]

Describe the bug

Hello! Here's a segfault for a fresh install, for my first run:

; wezterm
 2020-12-08T10:09:58.359Z ERROR wezterm_gui::gui::termwindow > OpenGL initialized! Mesa Intel(R) HD Graphics 520 (SKL GT2) OpenGL ES 3.2 Mesa 20.2.2 is_context_loss_possible=false
 2020-12-08T10:09:58.381Z ERROR wezterm_term::terminalstate  > Unhandled OSC  10 rgb:
 2020-12-08T10:09:58.381Z ERROR wezterm_term::terminalstate  > Unhandled OSC  11 rgb:
zsh: segmentation fault  wezterm

Environment (please complete the following information):

• OS:Debian
• Version:

; wezterm -V
wezterm 20201101-103216-403d002d

(this did not segfault)

To Reproduce

Run wezterm

Configuration

I didn't make a wezterm.lua configuration file.

Expected behavior

Not segfault

Additional context

I have no idea how to debug things :D

Thanks!

[wez]

Hello!
Sorry your first experience wasn't better!
A segfault is unusual: this is a Rust program after all!

Did you install one of the pre-built .debs? If so, is it reasonably close to the debian version of your distro? I'm wondering if perhaps it might be an ABI related fault. You might consider building from source if you think that may be factor.

You can get a lot more (probably irrelevant, but potentially interesting to me) debug information if you start wezterm thus: RUST_LOG=trace wezterm 2> /tmp/wezterm.log and convey that log to me; attaching to this issue is easiest but I'm also fine with email or some other means if you prefer!

For the segfault itself, I'm not expecting to see a huge amount of info here in the optimized binary, but gdb may provide some clues:

; gdb wezterm-gui
(gdb) run
<wait for segfault>
(gdb) bt
<please capture this section for me!>

(Note that wezterm spawns wezterm-gui, and since that is the most likely candidate for having the problem, gdb'ing that seems to make the most sense, rather than faffing with follow-fork)

If the stack trace isn't terribly useful, it may be worth building from source per the above link but omitting the --release flag during the build (eg: just cargo build) and gdb'ing target/debug/wezterm-gui directly.

Here's a pic to keep you company while debugging:

[katef]

This is the 20201101-103216-403d002d release, I got the debian package here from github.

Backtrace according to gdb, looks like this package has no symbols:

(gdb) run
Starting program: /usr/bin/wezterm-gui 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6fa9700 (LWP 27265)]
[Detaching after fork from child process 27266]
[New Thread 0x7ffff6d52700 (LWP 27267)]
[New Thread 0x7ffff6a47700 (LWP 27279)]
[New Thread 0x7ffff49c9700 (LWP 27283)]
[New Thread 0x7fffe19aa700 (LWP 27284)]
[New Thread 0x7fffe11a9700 (LWP 27285)]
[New Thread 0x7fffe09a8700 (LWP 27286)]
 2020-12-10T07:50:48.085Z ERROR wezterm_gui::gui::termwindow > OpenGL initialized! Mesa Intel(R) HD Graphics 520 (SKL GT2) OpenGL ES 3.2 Mesa 20.2.2 is_context_loss_possible=false
 2020-12-10T07:50:48.099Z ERROR wezterm_term::terminalstate  > Unhandled OSC  10 rgb:
 2020-12-10T07:50:48.099Z ERROR wezterm_term::terminalstate  > Unhandled OSC  11 rgb:

Thread 1 "wezterm-gui" received signal SIGSEGV, Segmentation fault.
0x00007ffff59ecd2b in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(gdb) bt
#0  0x00007ffff59ecd2b in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#1  0x00007ffff5b54316 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#2  0x00007ffff59ce2c5 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x00007ffff59cf0c3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x00007ffff5011538 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x0000555555bca982 in glium::ops::clear::clear ()
#6  0x000055555579c49a in ?? ()
#7  0x0000555555a80d0f in ?? ()
#8  0x0000555555a637c9 in <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop ()
#9  0x0000555555770373 in ?? ()
#10 0x000055555576e0e7 in ?? ()
#11 0x00005555557edd03 in ?? ()
#12 0x00005555557497f9 in ?? ()
#13 0x0000555556421391 in std::rt::lang_start_internal ()
#14 0x0000555555771082 in ?? ()
#15 0x00007ffff7952cca in __libc_start_main (main=0x555555771060, argc=1, argv=0x7fffffffe498, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe488)
    at ../csu/libc-start.c:308
#16 0x0000555555717889 in ?? ()
(gdb) 

log attached:
wezterm.log

[katef]

it felt like a bunch of ram was being allocated, so I ran under strace -f and lo:

[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad7889f4) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788980) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788780) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad788774) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788630) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788a00) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad7889f4) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788980) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788850) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad788844) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788700) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788a00) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad7889f4) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788980) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788780) = 0

(lots of those, as if in a loop)
and eventually:

[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad788774) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788630) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_CREATE, 0x7fffad788a00) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fffad7889f4) = 0
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP, 0x7fffad788980) = -1 ENOMEM (Cannot allocate memory)
[pid 27576] ioctl(15, DRM_IOCTL_I915_GEM_MMAP_GTT, 0x7fffad7889f0) = 0
[pid 27576] mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 15, 0x109fc8000) = -1 ENOMEM (Cannot allocate memory)
[pid 27576] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x24} ---
[pid 27576] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fd66ba7de30}, NULL, 8) = 0
[pid 27576] rt_sigreturn({mask=[]})     = 64
[pid 27576] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x24} ---

[wez]

Hmm, not sure how much I trust that backtrace given the lack of symbols, but there are two things that I think are worth trying:

1. Put this in your wezterm.lua config file:

return {
  front_end = "Software",
}

This should put Mesa into llvmpipe rasterizer mode rather than trying to use the native graphics drivers, which is seemingly where the fault is occurring.

1. Try a nightly build. There have been a couple of changes to accommodate very early resizing; I can see from the logs your provided that the terminal is resized from 80x24 to 120x17 almost immediately after being mapped.

[katef]

I tried running under Xephyr, and that works fine.

I tried with your front_end = "Software" (using my native display, without Xephy), and that also works fine.

This time I noticed that running on the native display (and without your setting), an X window does in fact open, but very briefly before the segfault. And it doesn't seem to be re-drawn (that is, its area shows whatever was on the screen beforehand).

[wez]

I'm wondering if you're experiencing this or a variant of this more general Iris/Mesa/Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955747
A quick search for iris debian segfault shows a number of similar sounding things out there :-(

[wez]

There's a possible solution at the bottom of that page: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955747#32

[katef]

Hm, that's curious. I am using 20.2.2-1, but I don't see this same bug with glxgears or glxdemo; they run fine for me.

I'm also a little averse to touching things to do with graphics drivers, because I know if I do that, I won't be able to use my machine for a week while I fix whatever I break, and I need to use it for work :)

[wez]

Since this appears to be a crash inside the iris drivers and doesn't manifest elsewhere, and I don't have a device with the same hardware to try to reproduce this, I don't think there's a lot that can be done from this side beyond selecting the Software front end. The software frontend (llvmpipe) is pretty good so perhaps that's sufficient?

[katef]

It's actually too slow for me to use! But no matter. I don't have any other ideas, too. I'm happy to close this ticket, and leave this for whoever might find it in the future...