Wezterm crashes under Hyprland when second instance is launched on the same display and fractional scaling is on

[pshirshov]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Hyprland

WezTerm version

wezterm 20230712-072601-f4abf8fd

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

warning: queue 0x55e9f26c0ec0 destroyed while proxies still attached:
  wl_registry@32 still attached
02:14:04.674  WARN   wezterm_gui::termwindow::resize > cannot resize window to match Some(RowsAndCols { rows: 60, cols: 160 }) because window_state is MAXIMIZED
02:14:07.219  ERROR  wezterm_mux_server_impl::local  > writing pdu data buffer: Broken pipe (os error 32)
02:14:07.231  WARN   wezterm_gui::termwindow::resize > cannot resize window to match Some(RowsAndCols { rows: 60, cols: 160 }) because window_state is MAXIMIZED
wl_surface@39: error 2: Buffer size (1296x1131) is not divisible by scale (2)
02:14:07.241  ERROR  wezterm_gui                     > running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 2, object_id: 39, object_interface: "wl_surface", message: "" }): Protocol error (os error 71); terminating
warning: queue 0x55e9f21d4b20 destroyed while proxies still attached:
  wl_callback@55 still attached
  wl_callback@49 still attached
  wl_surface@39 still attached
  xdg_wm_base@24 still attached
  wl_surface@23 still attached
  wl_data_device@20 still attached
  wl_pointer@18 still attached
  zwp_text_input_v3@17 still attached
  wl_keyboard@16 still attached
  zwp_primary_selection_device_v1@15 still attached
  zwp_primary_selection_device_manager_v1@3 still attached
  wl_data_device@14 still attached
  wl_output@13 still attached
  wl_output@12 still attached
  wl_output@11 still attached
  zwp_text_input_manager_v3@10 still attached
  zxdg_decoration_manager_v1@9 still attached
  wl_seat@8 still attached
  wl_data_device_manager@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached

To Reproduce

1. Launch WezTerm instance under multi-head Hyprland config with fractional scaling on (just run wezterm) in another terminal
2. Launch another instance on the same display (wezterm again)
3. WezTerm will crash with stack like the above

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response

[aspizu]

I can reproduce the same issue on Arch Linux.
One thing I noticed.
It does not crash if the first instance is NOT in focus.

[pshirshov]

In my case it always crashes, but focus on Hyprland is a tricky matter.

[vandalt]

I noticed a similar issue on sway. Wezterm sometimes crashes and I get a notification with the following error:

running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 2, object_id: 44, object_interface: \"wl_surface\", message: \"\" }): Protocol error (os error 71)

[lutzgo]

On Hyprland I got the same error

warning: queue 0x55a9b2468150 destroyed while proxies still attached:
  wl_registry@30 still attached
11:28:25.206  WARN   wezterm_gui::termwindow::resize > cannot resize window to match Some(RowsAndCols { rows: 24, cols: 80 }) because window_state is MAXIMIZED
warning: queue 0x55a9b1f78490 destroyed while proxies still attached:
  wl_callback@37 still attached
  zwp_primary_selection_offer_v1@4278190085 still attached
  wl_data_offer@4278190081 still attached
  wl_data_offer@4278190080 still attached
  xdg_wm_base@22 still attached
  wl_surface@21 still attached
  wl_data_device@18 still attached
  wl_pointer@16 still attached
  zwp_text_input_v3@15 still attached
  wl_keyboard@14 still attached
  zwp_primary_selection_device_v1@13 still attached
  zwp_primary_selection_device_manager_v1@3 still attached
  wl_data_device@12 still attached
  wl_output@11 still attached
  zwp_text_input_manager_v3@10 still attached
  zxdg_decoration_manager_v1@9 still attached
  wl_seat@8 still attached
  wl_data_device_manager@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached

Wezterm Version: wezterm 20230712-072601-f4abf8fd

[aspizu]

Seems like this issue has been resolved.

[enimax-anime]

Seems like this issue has been resolved.

Can confirm. Building from source fixed the issue for me.

[jokeyrhyme]

possibly related to #3765

[real-or-random]

I see this when opening a second tab

• display scaling is set to 150% in GNOME 45.3
• wezterm 20240203-110809-5046fc22
• hide_tab_bar_if_only_one_tab = true
• window_decoration = "RESIZE"

[  54742.983] wl_display@1.error(wl_surface@64, 2, "Buffer size (1527x12) must be an integer multiple of the buffer_scale (2).")
wl_surface@64: error 2: Buffer size (1527x12) must be an integer multiple of the buffer_scale (2).
09:41:37.587  ERROR  wezterm_gui                     > running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 2, object_id: 64, object_interface: "wl_surface", message: "" }): Protocol error (os error 71); terminating 

[jokeyrhyme]

The window size is influenced by your font, font size, padding, etc
So, on my system, using Iosevka with the default font size (12?) and the following works as a temporary workaround

config.window_padding = {
  bottom = "5px",
  left = "1cell",
  right = "1cell",
  top = "5px",
}

In the long term, we probably need to adjust the window resizing code so that it internally always clamps/snaps to valid sizes

Edit: or, perhaps the buffer size can be restricted to valid sizes without changing the draw area i.e. buffer size >= draw area, having a tiny invisible part of the buffer as necessary

[stephanlamoureux]

I can't even get wezterm to open in Hyprland at all so you're doing better than I am.

[github-actions]

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.