Closed dsvensson closed 3 years ago
There's also an issue with really laggy user experience / high CPU, stuttering resizing of the window and so on. Reverting to last release fixes both issues.
High CPU might mean that the Software renderer is in use instead of the GPU based renderer.
Please run wezterm like this:
RUST_BACKTRACE=1 RUST_LOG=info wezterm 2>/tmp/wezterm.trace
then reproduce the problem and share the trace here. The trace may be quite large; what I'm looking for is largely the stuff about opengl, as well as what I'm assuming will be a stacktrace from a panic at the bottom.
Sorry for the delay, here it is. Worth noting is that the CreateWindowSurface
error comes before the maximizing of the window (maximizing is what reliably leads to the crash in the 20200718-095447-d2315640
release).
Another weird thing is that my laptop with a GeForce GTX 1650, same Ubuntu 20.04, same version of the NVIDIA driver, same set of GNOME extensions etc, the same 20200718-095447-d2315640
wezterm version can maximize without crashing. Although there, when maximizing, the fonts look crap as if stretched such that some parts (horizontal or vertical lines) of the characters look like they're twice the intended width or height. The original window size renders the fonts correctly, but when slowly resizing the window for example horizontally, the fonts kind of ripples like water, oddly enough mostly in the left part of the window, but that's another issue.
Thanks for the info!
What I think is happening is that opengl isn't initializing correctly because the selected config has 0 alpha; you can see that those modes are listed first in the filtered set of matching configs. When that happens we should fall back to Software rendering, which sounds like it would match up to the poor performance you mentioned.
In addition, the error code it prints out means "Connection closed, exceeding request length that server accepts". My theory is that when you maximize the window we're allocating a really big bitmap as backing (what's your overall screen resolution?) and then try to blit the whole thing in a single request.
I adjusted the config matching code in https://github.com/wez/wezterm/commit/4605244af79648f7c26edf795b3e6f277352ad1f so that we should pick a more reasonable alpha and be less likely to trigger the bad match error when creating the surface.
Would you mind trying a nightly build to pick up that commit?
If I'm right then that should get you fixed up.
Also, if I'm right, running wezterm start --front-end Software
and maximizing should reproduce the same crash for you on the prior release.
I'd love to hear if the nightly build is working for you if you have a chance to try it out this weekend!
Same... the crash comes with maximizing, and the GL warning on startup:
Running `target/release/wezterm start`
2020-08-31T18:42:33.720Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: EGL CreateWindowSurface: BAD_MATCH, with_egl_lib(libEGL.so) failed: EGL CreateWindowSurface: BAD_MATCH
2020-08-31T18:42:38.399Z ERROR wezterm > X11 connection is broken: ClosedReqLenExceed Connection closed, exceeded request length that server accepts.; terminating
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
after 320 requests (319 known processed) with 0 events remaining.
2020-08-31T18:42:38.412Z ERROR wezterm::mux > read_pty EOF: tab_id 0
wezterm on master is 📦 v0.1.0 via 🦀 v1.46.0-nightly ❯ git show HEAD | head -10
commit 99b8fb2612025c8824f97b1dd7b7bcb2313d21c0 (HEAD -> master, origin/master, origin/HEAD)
Author: Wez Furlong <wez@wezfurlong.org>
Date: Sat Aug 29 10:45:01 2020 -0700
wezterm: add tab_max_width config option
This allows setting the maximum width of a tab in the tab tab.
It defaults to 16 glyphs in width.
refs: https://github.com/wez/wezterm/issues/255
Just to rule it out, I also updated rust to latest, and as expected, same behavior.
And as for wezterm start --front-end Software
, it does indeed reproduce the crash in 20200620-160318-e00b076c
.
What is the resolution of your display? I think this may be related to the size of the screen
4k, 3840x2160, no problem on my laptop with NVIDIA 1650 instead of 980 Ti connected to the same monitor. Same Ubuntu version, 20.04, up-to-date packages on both.
I've made a few changes to opengl config detection and fallback; would you mind trying the latest master when you have a chance?
Maximizing works on one of my machines now, was broken on both a week ago or so, testing the other one tonight. :crossed_fingers:
I know that we have the weird resize issue open for you, but are both of your systems now maximizing ok?
Second computer verified. You can consider this resolved!
Ubuntu 20, installed using the ubuntu 20 nightly release from this page
I'm getting the same problem on wezterm -V
= wezterm 20210405-110924-a5bb5be8-95-gd5886e62
I'm using some gnome extension called Material Shell which maximizes things when starting by default. If I set it to a tiled mode then it actually doesn't crash.
Here's the trace:
2021-04-15T16:25:32.502Z INFO wezterm_mux_server_impl::local > setting up /run/user/1000/wezterm/gui-sock-16832
2021-04-15T16:25:33.216Z INFO wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) OpenGL ES 3.2 Mesa 20.2.6 is_context_loss_possible=false wezterm version: 20210405-110924-a5bb5be8-95-gd5886e62
2021-04-15T16:25:33.550Z ERROR wezterm_gui > X11 connection is broken: ClosedReqLenExceed Connection closed, exceeded request length that server accepts.; terminating
XIO: fatal IO error 0 (Success) on X server ":0"
after 6 requests (6 known processed) with 0 events remaining.
It's possibly worth mentioning I'm running this in a VM and haven't tried to get any fancy GPU passthru stuff working
I'll try building from source and see if I get the same issue
@wez yes I see this same issue when building from source
@hderms running WEZTERM_LOG=window=trace,wezterm_gui::termwindow=trace,info wezterm 2> /tmp/wezterm.txt
should capture some relevant window/resize data into /tmp/wezterm.txt
; please share the contents of that file with me!
@hderms also, when you start tiled, does it crash if you then manually maximize?
@wez yeah, it's 100% due to maximization in this specific instance. Starting it up with a split (i.e. not maximized)
Trying to maximize it:
I can reproduce this locally using:
WEZTERM_LOG=window=trace,info MESA_DEBUG=flush,context LIBGL_DEBUG=verbose EGL_LOG_LEVEL=debug __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json wezterm --config 'front_end="Software"' -n
and then maximizing.
wezterm isn't making any direct X11 requests that would hit the maximum request size of the X server. I believe this to be a bug in the llvmpipe Mesa component.
Your best bet is to enable GPU pass-through; I'm sorry that I don't have a workaround for this, but it's not directly controllable from wezterm :-/
@wez that's good to know. Thanks for spending your time looking into this.
I'm getting the same error message from X11 when running wezterm full screen (3840x2160), running under xrdp or tigervnc session on a 4K display (Xorg, no wayland).
Mostly use my desktop while physically present, then no problem on the same machine.
Under xrdp/tigervnc wezterm is using the Mesa component. Are we sure wezterm is not hitting the max request size "for real"? Could chunking the window into bands on the non-gpu-backend make a difference?
I've produced a tcpdump like wez described in #543 if that helps. https://drive.google.com/file/d/1dD5OBs-QvPNjjVCpugXBFSo60hdX2p5k/view?usp=sharing
wezterm doesn't directly send those requests: we just use opengl and it's mesa that is doing the underlying X11 stuff for those, so this is outside of wezterm's control.
I'm getting this same error on arch with most recent version of wezterm from the AUR (which recently got updated apparently); I don't believe it was happening prior to this. Perhaps it's the llvmpipe bug :/
Love wezterm anyway!
Having the same issue on a 4K screen. Looks to be from a recent system update in Fedora 36. Had the exact same version of WezTerm working fine yesterday, but maximizing it breaks it now after software updates.
Unfortunately I'm not on Silverblue to test out the rolled-back changes. Can't exactly pinpoint which version of the suspected problems in mesa that's causing the issue.
I have same issue with wezterm in fedora 36 gnome xorg
I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/6483 to get some input from the Mesa folks
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17155 is a proposed fix in Mesa
Tried latest wezterm nightly with mesa built from Dave Airlie's branch. Can confirm it resolves the issue for my wezterm🌟
wezterm_gui::termwindow > OpenGL initialized! llvmpipe (LLVM 11.0.0, 256 bits) 4.5 (Compatibility Profile) Mesa 22.2.0-devel (git-dea83f6862) is_context_loss_possible=false wezterm version: 20220621-115337-6767144a
It will be in 22.2.0+, and has been backported to 21.1.x, so (unless there are issues) it will be in 22.1.3
Confirmed that maximizing works now on Fedora 36 with all latest updates installed. Thanks a bunch!
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Describe the bug
Maximize => crash, "X11 connection is broken: ClosedReqLenExceed"
Environment (please complete the following information):
To Reproduce
Maximize.
Configuration
Expected behavior
Window maximized
Screenshots
Additional context
Have a GNOME extension, Pixel Saver that puts window border icons (close/maximize/minimize) in the GNOME top bar, perhaps that causes X to return something unexpected to wezterm.