Xorg receives SIGALRM and freezes during screen lock with Wine/GE-Proton application running - nvidia-driver-580-open, Ubuntu 24.04

Graphics / Linux Linux
1

Environment

Component Details
OS Ubuntu 24.04 LTS
Kernel 6.17.0-19-generic (#19~24.04.2-Ubuntu SMP PREEMPT_DYNAMIC)
GPU NVIDIA GeForce RTX 4070 Ti
Driver nvidia-driver-580-open 580.126.09
Session X11, GNOME Shell 46.2 / mutter 46.2
nvidia_drm modeset 1
NVreg_PreserveVideoMemoryAllocations 1

Application running at time of freeze:

  • Lutris (Flatpak) 0.5.22

  • Battle.net Launcher via GE-Proton10-34 / umu-launcher 1.4.0

  • DXVK enabled, WINEESYNC=1, WINEFSYNC=1

Behavior

Pressing Ctrl+L to lock the screen while Battle.net is running via Lutris/GE-Proton causes the display to freeze permanently. TTY remains accessible. systemctl restart gdm recovers the session.

Does not occur when Battle.net is closed before pressing Ctrl+L. 100% reproducible on demand.

What the logs show

1. DBus trace at moment of freeze dbus-monitor --session "interface='org.gnome.ScreenSaver'"

Lock request reached gnome-shell. No reply was ever returned. Log ends here.

method call sender=:1.60 -> destination=:1.74
    path=/org/gnome/ScreenSaver; member=Lock

method call sender=:1.74 -> destination=:1.33
    path=/org/gnome/ScreenSaver; member=Lock

2. strace on gnome-shell at moment of freeze strace -p <gnome-shell pid> -e trace=all -T -tt

gnome-shell blocked indefinitely on poll() on fd=10. Confirmed via ss as the X11 Unix socket connected to Xorg. gnome-shell sent a request to Xorg and Xorg never responded.

poll([{fd=10, events=POLLIN}], 1, -1

3. strace on Xorg at moment of freeze strace -p <xorg pid> -e trace=all -T -tt

Xorg was actively writing to client sockets and not blocked or hung when SIGALRM arrived from the kernel. After SIGALRM the process stopped responding entirely.

17:09:14.886203  writev(11, ...) = 32
17:09:14.886213  writev(11, ...) = 32
17:09:14.886222  writev(11, ...) = 32
17:09:14.900162  --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---

4. Kernel log

Clean throughout. No GPU errors, no hung task warnings, no OOM events.

2

Attached GDB to Xorg using handle SIGALRM pass noprint nostop initially to prevent destabilizing the session, then flipped to handle SIGALRM stop print before triggering the freeze. SIGALRM was caught successfully.

Backtrace of Thread 1 (Xorg main thread) at freeze:

#0  __GI_sched_yield ()  from libc.so.6
#1  ??                   from nvidia_drv.so
#2  ??                   from nvidia_drv.so
#3  ??                   from nvidia_drv.so
#5  ??                   from nvidia_drv.so
#7  ??                   from nvidia_drv.so

All frames are inside nvidia_drv.so. The main thread is spin-waiting inside the NVIDIA Xorg driver at the moment SIGALRM fires. Every other Xorg thread was idle in pthread_cond_wait in libgallium — uninvolved.

Two additional observations worth noting: DXVK_ENABLE_NVAPI=1 with nvapi64=n (native NVAPI DLL, not a Wine stub) is active in the Wine environment at freeze time. Also when GDB was left in pass noprint nostop mode the freeze did not occur, which suggests the signal delivery timing is part of the trigger condition.