SIGTRAP crash in `stream::session::join` due to deadlock with system tray/notification thread on Wayland

[Horcag]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your issue described in the documentation?

• [x] I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

When a streaming session is terminated (client disconnects), Sunshine attempts to update its system tray icon and send a notification. On a Wayland session (Hyprland) with a notification daemon (dunst or swaync), this action causes the notification thread to hang indefinitely. This, in turn, blocks the main session teardown logic. After a timeout, a watchdog in the session management code triggers a deliberate debug_trap, terminating the entire Sunshine process with a SIGTRAP signal.

This crash often leads to a GPU hang, causing the entire graphical session to freeze. The session may recover after several minutes (likely due to a GPU reset by the kernel driver), but sometimes it requires a hard reboot (REISUB). The issue becomes more probable the longer the Sunshine process has been running, or after several successful connect/disconnect cycles.

Reproduction Steps:

1. Run Sunshine (built from source with debug symbols) on Arch Linux with Hyprland (Wayland) and a running notification daemon (e.g., dunst).
2. Connect a client and start a desktop stream.
3. Disconnect the client.
4. Observe that the Sunshine process hangs and then crashes with SIGTRAP.

Expected Behavior

Sunshine should handle an unresponsive notification daemon gracefully. If updating the system tray or sending a notification times out, it should log an error for that specific subsystem and continue the session teardown process without crashing the entire application. A non-critical component like notifications should not be able to cause a fatal application error that destabilizes the host's graphical environment.

Additional Context

This is not a random segfault but a deliberate application termination. A live GDB session and dbus-monitor confirm the exact failure mechanism:

1. dbus-monitor log shows a hang: A method_call to org.freedesktop.Notifications is sent, but no method_return or error is ever received, indicating the call is blocked. In one captured instance, the hang lasted over 500 seconds before the application crashed.
2. GDB backtrace confirms the deadlock:
   • The crashing thread (LWP 337170 in the attached log) is terminated by lifetime::debug_trap() inside stream::session::join (stream.cpp:1905), which acts as a watchdog.
   • The watchdog is triggered because the session teardown is blocked by the system tray thread (LWP 337630).
   • The system tray thread (LWP 337630) is stuck waiting on a condition variable inside tray_update.
   • The actual work is being done in the GTK/GLib main loop thread (LWP 337171), which is perpetually blocked inside a synchronous D-Bus call: g_dbus_proxy_call_sync -> notify_notification_close.

This proves that the notification thread hangs indefinitely, causing the session thread to time out and trigger a self-destruct.

The issue was reproduced with both dunst and swaync notification daemons. Setting NOTIFY_IGNORE_PORTAL=1 does not resolve the issue.

system-info.md

Host Operating System

Linux

Operating System Version

Arch Linux rolling; kernel 6.16.1-arch1-1; Hyprland 0.50.1.

Architecture

amd64/x86_64

Sunshine commit or version

Built from source at commit 2f7657a1 (Version 0.0.0.2f7657a1)

Package

other (self built)

GPU Type

Intel

GPU Model

Intel Iris Xe Graphics (Alder Lake-P GT2)

GPU Driver/Mesa Version

Mesa: 25.1.7-1

Capture Method

wlroots (Linux)

Config

adapter_name = /dev/dri/renderD129
audio_sink = null
encoder = vaapi
hevc_mode = 0
min_log_level = 0
notify_pre_releases = enabled
output_name = 1
stream_audio = false

Apps

{
  "env": {
    "PATH": "$(PATH):$(HOME)/.local/bin"
  },
  "apps": [
    {
      "name": "Desktop",
      "image-path": "desktop.png"
    },
    {
      "name": "Low Res Desktop",
      "image-path": "desktop.png",
      "prep-cmd": [
        {
          "do": "xrandr --output HDMI-1 --mode 1920x1080",
          "undo": "xrandr --output HDMI-1 --mode 1920x1200"
        }
      ]
    },
    {
      "name": "Steam Big Picture",
      "detached": [
        "setsid steam steam://open/bigpicture"
      ],
      "prep-cmd": [
        {
          "do": "",
          "undo": "setsid steam steam://close/bigpicture"
        }
      ],
      "image-path": "steam.png"
    }
  ]
}

Relevant log output

dbus-monitor output showing the hang:

method call time=1756291776.338686 sender=:1.589 -> destination=:1.25 serial=64 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=CloseNotification
   uint32 0

# --- HANG STARTS HERE ---

method call time=1756292286.992493 sender=:1.766 -> destination=org.freedesktop.Notifications serial=4 path=/org/freedesktop/Notifications;  interface=org.freedesktop.Notifications; member=GetCapabilities

# --- HANG ENDS ~510 SECONDS LATER WHEN PROCESS IS KILLED ---

The full backtrace of all threads captured during the hang is too long for a GitHub comment. It has been uploaded here: CLICK

Key threads are:

• Thread 3886 (LWP 337170): The watchdog thread that triggered the SIGTRAP.
• Thread 4027 (LWP 337630): The session thread blocked waiting for the tray update.
• Thread 3887 (LWP 337171): The tray/notification thread hanging on a D-Bus call to notify_notification_close.

[ReenigneArcher]

Likely the same as https://github.com/LizardByte/tray/issues/45

[Horcag]

Thanks for the quick response. I will recompile with -D SUNSHINE_ENABLE_TRAY=0 as a workaround for now, as suggested by other users in issue #2778.

[Kishi85]

I've seen this occur once so far on Bazzite (had to reboot to fix it) and I'm wondering if we could make the tray a config setting so it can be easily disabled at runtime without having to recompile.

I'll have a look at the code and try to make a PR.

[s-cerevisiae]

Constantly happening here.

[LizardByte-bot]

It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!

[s-cerevisiae]

Yes this is critical for my workflow. Don't make me blind type my password with KDE Connect, it sucks.