Closed jarod closed 8 months ago
Please launch wezterm with wayland debugging enabled:
WAYLAND_DEBUG=1 wezterm
and share the output here
Please launch wezterm with wayland debugging enabled:
WAYLAND_DEBUG=1 wezterm
and share the output here
here is the output: https://gist.github.com/jarod/d7bb7f5ee5fa4c9895a7b4b5e3ce7f4f
Same issue on Fedora 38 when trying to resize Wezterm using win+down key combination.
A similar issue exists for me on wezterm 20230408-112425-69ae8472
, using the Flatpak installation org.wezfurlong.wezterm
, also on Fedora (Silverblue 38, running GNOME). No configuration file.
Sometimes just the app crashes, other times GNOME crashes, throwing the user back to the login screen. It seems to trigger when quickly moving the Wezterm window between screens.
My screens have mixed scaling, one running at 100% and another at 200%. Could that be related to the final error message? (Sorry, not that familiar with Wayland's internals.) I read somewhere that GNOME doesn't implement fractional scaling while other Wayland compositors do (e.g. KDE's), not sure whether that's related. I can't reproduce the error after switching both screens to 100%.
[ 26911.546] -> wl_surface@70.set_buffer_scale(1)
[ 26911.558] -> wl_surface@70.commit()
[ 26911.570] wl_surface@74.leave(wl_output@6)
[ 26911.595] wl_surface@74.enter(wl_output@7)
[ 26911.612] -> wl_surface@74.set_buffer_scale(1)
[ 26911.625] -> wl_surface@74.commit()
[ 26911.637] wl_callback@27.done(508797)
[ 26911.681] wl_display@1.error(wl_surface@68, 2, "Buffer size (803x12) must be an integer multiple of the buffer_scale (2).")
wl_surface@68: error 2: Buffer size (803x12) must be an integer multiple of the buffer_scale (2).
06:36:46.549 ERROR wezterm_gui > running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 2, object_id: 68, object_interface: "wl_surface", message: "" }): Protocol error (os error 71); terminating
Can post the full logs as a Gist if needed. Thanks for your work on Wezterm!
It looks like @jarod and @LouisJackman have a different issue than I do. They have the issue where they have a window size not divisible by 2.
I thought @wez fixed it in https://github.com/wez/wezterm/issues/3234
My issue is:
[2713772.141] wl_display@1.error(nil, 7, "importing the supplied dmabufs failed")
[destroyed object]: error 7: importing the supplied dmabufs failed
15:12:45.734 ERROR wezterm_gui > running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 7, object_id: 0, object_interface: "<unknown>", message: "" }): Protocol error (os error 71); terminating
It doesn't happen when front_end = "WebGpu"
but does for Software
and OpenGL
on nvidia
535.34.
Maybe it can give any hints, but this is my case: Gentoo, Apple M1 machine, Hyprland with 1.5 DPI scale
In order to reproduce crash I need to invoke terminal while I am hovering already existing one. If I for example create terminal on blank workspace and then create one more on another empty workspace and move one next to another, nothing will crash. But if I hover wezterm and invoke
bind = $mainMod, T, exec, wezterm
main process crashes with mentioned error.
UPD: just found that if I execute wezterm
inside wezterm, it will crash too, but not always. In one of 10 attempts it worked out.
Isn't this a duplicate of #2445? I've read https://github.com/hyprwm/Hyprland/issues/509 and.. Is this issue with wlroots? I would really love if someone could point where this problem can be tracked. Maybe wayland/wayland#194? If it really needs whole new API rewrite and no activity for 7 months, that's not inspiring. Maybe I even fall back to alacritty, even though it is much slower :(
If you were affected by this issue, could you give the latest nightly build a try? It's possible that https://github.com/wez/wezterm/pull/4322 improved the situation
So far, I was unable to observe the bug using the latest nightly build.
Using the stable AppImage, the bug occured in 3/10 attempts. Using the latest nightly build, it did not occur even once in >50 attempts.
If you were affected by this issue, could you give the latest nightly build a try?
Finally found some time to compile wezterm manually because Hyprland update broke wezterm (#4483). Can confirm latest nightly works for me and resolves both of these issues. Running hyprland on gentoo on M1 machine :) Thank you for this awesome terminal!
Apologies for the very late reply. I can't reproduce the crash anymore, currently on version 20230712-072601-f4abf8fd
. So, thanks for the fix! Interestingly, while that's a version later than my original report of the issue, it seems to predate the merging of #4483. I suppose it's also possibly due to a Gnome change in recent months.
I am still able to reproduce the error on the latest nightly appimage on version on Fedora 39 Silverblue, Wayland. This is not matter if I use front_end=Software
or front_end=WebGpu
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.
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
WezTerm version
20230408-112425-69ae8472
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
drag and move the wezterm window then it just crashed, not 100%, but it happen a lot
To Reproduce
No response
Configuration
~/.config/wezterm/wezterm.lua
:Expected Behavior
No response
Logs
Anything else?