Wezterm crashes (and even seems to crash the `dbus` daemon) when using `dbus-broker` and the "dummy" Xorg video Driver

adamency commented 9 months ago

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

Linux X11

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

i3

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

My system is a linux machine used for remote access on Arch Linux, X11, i3, lightdm, and a dummy X monitor (uses the xf86-video-dummy Xorg driver).

Arch Linux very recently migrated to dbus-broker from dbus-daemon. Since the update, wezterm always crashes at launch and even seems to break the dbus daemon. What effectively happens is that i3/Xorg/lightdm forcefully restarts and the previous session is lost.

This never happened before the change.
I have also successfully verified that this does not happen either if I connect a real monitor to the screen and thus make Xorg use the nvidia driver instead.
I am also able to launch xterm konsole and alacritty successfully when using the dummy monitor.

To Reproduce

Linux machine
Xorg installed
Using a Dummy Monitor with the "dummy" driver (xf86-video-dummy).
Connected via VNC (using rustdesk on my end). I guess it's the only way to actually display a dummy monitor, but I don't know for sure.
Run wezterm --skip-config when connected to the Xorg session via VNC on the dummy monitor.

-> The Xorg session crashes

Configuration

Here is my dummy monitor config for Xorg (in /etc/X11/xorg.conf.d/10-headless.conf on Arch)

Section "Monitor"
        Identifier "dummy_monitor"

        HorizSync   5.0 - 100.0
        VertRefresh 5.0 - 200.0

        Modeline "2584x1440_50.00" 259.05 2584 2760 3040 3496 1440 1441 1444 1482

EndSection

Section "Device"
        Identifier "dummy_card"
        VideoRam 2048000
        Driver "dummy"
EndSection

Section "Screen"
        Identifier "dummy_screen"
        Device "dummy_card"
        Monitor "dummy_monitor"
        DefaultDepth 24
        SubSection "Display"
            Modes "2584x1440_50.00"
        EndSubSection
EndSection

Section "ServerFlags"
        Option "BlankTime" "60"
EndSection

Expected Behavior

Wezterm runs without issues.

Logs

It is very difficult to provide wezterm logs as the Xorg session crashes right after launching wezterm. Here are the logs I can see after launching Wezterm, right before the session crashes:

wez commented 9 months ago

and even seems to break the dbus daemon.

FWIW, if wezterm can do something (even if/especially if what it is doing is wrong) to make dbus crash, that is a bug in the dbus daemon and should be reported to the maintainers.

wez commented 9 months ago

the MESA errors suggest a problem with finding a working GPU, which I suppose makes sense for a dummy environment. You may want to try setting front_end = "Software" to use CPU rendering.

If you want to have a better chance of seeing wezterm logs, I would suggest spawning wezterm from outside, while explicitly setting the display to the appropriate thing, something like:

DISPLAY=:1 wezterm

adamency commented 9 months ago

Thanks, front_end = "Software" does indeed solve the crash issue. It's a bit sad, but it works.

I still wanna point out I didn't have any issue before this dbus provider change, and that other "GPU-accelerated" terminals like alacritty and kitty still work, with the GPU.

This may be a bug in dbus-broker (and if I'm not mistaken this would mean wezterm and alacritty are using different dbus Rust bindings which seems unprobable ?) but I'm not proficient enough in it to understand exactly where the problem comes from.

I guess I'll leave this issue at that for now, cause I don't currently have time to investigate further unfortunately.

adamency commented 9 months ago

FWIW, here is the full error log when launching wezterm with front_end = "WebGpu" (which also make wezterm crash, but at least not the full X session like with front_end = "OpenGL"):

03:33:17.033  WARN   window::os::x11::connection > Unable to resolve appearance using xdg-desktop-portal: get_appearance.read_setting: Reading xdg-portal org.freedesktop.appearance color-scheme: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
libEGL warning: DRI2: failed to authenticate
03:33:17.306  ERROR  env_bootstrap               > panic at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.18.0/src/backend/direct.rs:778:18 - !?
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: __libc_start_main
  23: <unknown>

thread 'main' panicked at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.18.0/src/backend/direct.rs:778:18:
Error in Surface::configure: Validation Error

Caused by:
    Not enough memory left.

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and here is my GPU info fetched by wezterm:

[
    {
        "backend": "Vulkan",
        "device": 7684,
        "device_type": "DiscreteGpu",
        "driver": "NVIDIA",
        "driver_info": "545.29.06",
        "name": "NVIDIA GeForce RTX 2080 Ti",
        "vendor": 4318,
    },
    {
        "backend": "Gl",
        "device": 0,
        "device_type": "Cpu",
        "name": "llvmpipe (LLVM 16.0.6, 256 bits)",
        "vendor": 65541,
    },
]

I don't know what is the exact context of the OOM message here, but I have 29GB of RAM left and the 11GB of the GPU's RAM used at <1%.

wez commented 9 months ago

Couple of quick things:

wgpu is very pedantic about having working GPU and driver combinations. I'd be surprised it if ever works in a virtualized/dummy environment. That panic is not something I would worry about; the resolution is to not use wgpu there.
There are at least two different sets of dbus bindings in the rust ecosystem, so it doesn't sound crazy for there to be a bug in the https://docs.rs/zbus/latest/zbus/ crate that we use here. However, from the logs, wezterm doesn't appear to crash due to dbus. It seems like the daemon crashes and, because the rest of the environment depends on it, that takes out everything else

I'd suggest reaching out to the dbus-broker and zbus folks to see if they are aware of this interaction and to see if you can help collect more data for them to figure out how to resolve this.

adamency commented 9 months ago

Again, thanks for your answer. I'll post an issue upstream if I find the time.

github-actions[bot] commented 8 months ago

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.

wez / wezterm