running message loop: Error while flushing display: Broken pipe (os error 32); terminating

[zw963]

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

Linux Wayland

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

mutter

WezTerm version

20240203-110809-5046fc22

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

╰─ $ 2 wezterm -n 18:21:09.293 ERROR wezterm_gui > running message loop: Error while flushing display: Broken pipe (os error 32); terminating warning: queue 0x55601c8505f0 destroyed while proxies still attached: wl_buffer@54 still attached wl_buffer@27 still attached wl_buffer@25 still attached wl_buffer@24 still attached wl_buffer@53 still attached wl_buffer@58 still attached wl_buffer@29 still attached wl_buffer@56 still attached wl_buffer@55 still attached wl_buffer@57 still attached wl_buffer@28 still attached wl_subsurface@47 still attached wl_surface@46 still attached wl_subsurface@45 still attached wl_surface@44 still attached wl_subsurface@43 still attached wl_surface@42 still attached wl_subsurface@41 still attached wl_surface@40 still attached wl_subsurface@39 still attached wl_surface@38 still attached xdg_wm_base@21 still attached wl_surface@20 still attached wl_data_device@17 still attached wl_pointer@15 still attached zwp_text_input_v3@14 still attached wl_keyboard@13 still attached zwp_primary_selection_device_v1@12 still attached zwp_primary_selection_device_manager_v1@3 still attached wl_data_device@11 still attached zwp_text_input_manager_v3@10 still attached wl_seat@9 still attached wl_subcompositor@8 still attached wl_data_device_manager@7 still attached wl_output@6 still attached wl_shm@5 still attached wl_compositor@4 still attached

To Reproduce

This issue happen when i switch to use fractional scaling on GNOME + Wayland then reboot,

after reset use gsettings reset org.gnome.mutter experimental-features, but it still not work.

Configuration

No config.

Expected Behavior

No response

Logs

No response

Anything else?

No response

[zw963]

I workaround this issue with remove all my dot files/directory in my Arch linux $HOME folder, wezterm -n start works now.

[zw963]

I don't know what happen, i guess some dot config broken this.

For now, i move all my old dot config, dot config folder into a dot_backup folder, if anyone can give some clue about this, i can try to find broken wezterm config out in dot_backup folder.

But, not a big deal anyway, feel free to close this issue.

[ovidiu]

I get the same error on a fresh install of Ubuntu 24.04 (Wayland). So no funny dotfiles yet. Same version as @zw963 .

If I switch to nightly, then the crash doesn't happen, but I get a wezterm window with no decoration. I can't move it, resize it etc. I can't even make it full-screen with Alt+Enter.

[ovidiu]

I played around a bit and found that one of the solutions proposed for a separate issue (#5340) worked for me: setting WAYLAND_DISPLAY=1. Apparently this is supposed to disable Wayland support in WezTerm?

Anyway, I edited /usr/share/applications/org.wezfurlong.wezterm.desktop and changed the Exec line from

Exec=wezterm start --cwd .

to

Exec=env WAYLAND_DISPLAY=1 wezterm start --cwd .

And now WezTerm seems to start and run without any issues. Both the regular build and the nightly.

[zw963]

Hi @ovidiu , although this issue is gone for me, i still added env as you.

BTW: you don't need change /usr/share/applications/org.wezfurlong.wezterm.desktop, because it will override when you update wezterm use system package manager, you can copy org.wezfurlong.wezterm.desktop into ~/.local/share/application, and edit file there.

[zw963]

Hi, add env WAYLAND_DISPLAY=1 cause issues for me, e.g. i even can't start my emacsclient from within wezterm after set this because my emacs build with wayland support, i switch back anyway.

[ovidiu]

it will override when you update wezterm

Good point, thanks!

[wez]

re: WAYLAND_DISPLAY, that's a rather oblique way to disable wayland support. https://wezfurlong.org/wezterm/config/lua/config/enable_wayland.html is the option to use for that.

re: wayland on nightly, please try the very latest nightly build as a number of updates for wayland support have just been merged.

[zw963]

I am current installed wezterm-git 20240504.174056.f01397ea-1 from arch linux, this version is not enough, right?

[zw963]

Okay, i am building from source code, current version.

 ╰─ $ wezterm --version
wezterm 20240505-175915-8fa4ba9a

I will report here if any issue happen.

[zw963]

Hi, @wez , i can reproduce exactly same bug in #3221 use latest main branch, after hibernate then wake up, i will add more detail there.

[JonnieCache]

I'm also seeing this same behavior on ubuntu 24.04. The stable wezterm from the apt repo fails with the given error, it works with wayland disabled via the env var, and the nightly build works but the window has no decoration, as someone else here has described.

[eld0]

I also have the same issue which happens if I few time toggle a fullscreen through a wezterm's hotkey (Alt+Enter) combination but if I use a native Gnome hotkey for a fullscreen mode - everything is working as expected.

[Lemonlemmings]

@wez - Thanks for the your recommendation of the nightly build, I was suffering the same issue and that did the trick for me.

[xz-dev]

Same in RiverWM (wlroot), and is it need WM developer to do anything to fix it?

[mrobinson]

I am seeing the same issue and I noticed that wezterm works properly when I change desktop display scaling to 100%. Both 150% and 200% do not seem to work.

[nooop3]

Except disable Wayland by config.enable_wayland = false, I can also just disable fancy tab style config.use_fancy_tab_bar = false to mitigate this issue.

--- edited font_size also related. only 12.0 works with use_fancy_tab_bar = false, 14.0 does not work either

[zw963]

In fact, since I raised this issue, I haven't encountered this problem again. :smile:

BTW: i use GNOME 46.4 + Wayland, i use 100% scale for display settings, but setting font scaling factor to 2.0, on a 32# dell monitor, and with following ENV settings:

export QT_AUTO_SCREEN_SCALE_FACTOR=0 export QT_SCALE_FACTOR=2 export QT_FONT_DPI=140

[MartinNowak]

Weirdly enough doubling the default dpi (config.dpi = 192) seems to help with my fractional 125% scaling.

> wezterm.gui.screens().active
{
    "effective_dpi": 192,
    "height": 1504,
    "name": "eDP-1",
    "scale": 2,
    "width": 2256,
    "x": 0,
    "y": 0,
}

Without fractional scaling (and config.dpi override).

> wezterm.gui.screens().active
{
    "effective_dpi": 96,
    "height": 1504,
    "name": "eDP-1",
    "scale": 1,
    "width": 2256,
    "x": 0,
    "y": 0,
}

Maybe the 1.25 scale gets ceiled to 2 and hence a doubled dpi is required. The font is indeed larger, so it seems to "work".

Also using that same version.

$  wezterm --version
wezterm 20240203-110809-5046fc22