-
-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maximizing leads to crash #249
Comments
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:
then reproduce the problem and share the trace here. |
Sorry for the delay, here it is. Worth noting is that the trace from 20200718-095447-d2315640
trace from 20200620-160318-e00b076c
various GL info
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 |
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. In addition, the error code it prints out means "Connection closed, exceeding request length that server accepts". I adjusted the config matching code in 4605244 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. |
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:
Just to rule it out, I also updated rust to latest, and as expected, same behavior. And as for |
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. 🤞 |
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 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:
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 |
@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. |
I can reproduce this locally using:
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🌟
|
|
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.
The text was updated successfully, but these errors were encountered: