Bug description
hyprlock crashes with SIGABRT while sitting idle on the lock screen. It's launched by hypridle, and when I return I see "your lock screen app has died". No user interaction triggers the crash — it happens while the lock screen is displayed and idle.
This has been recurring since October 2025. I have 22 coredumps (mix of SIGABRT and SIGSEGV) across multiple hyprlock/Mesa versions.
Environment
- hyprlock: v0.9.3
- Hyprland: v0.54.3
- Mesa: 26.0.4
- GPU: Intel Arc B570 (Xe2, Battlemage)
- Kernel: 6.19.11-arch1-1
- OS: Arch Linux
PAM config
PAM config is complete with auth, account, and session — this is not the PAM issue from #953.
#%PAM-1.0
auth include system-login
account include system-login
session optional pam_keyinit.so force revoke
session include system-login
hyprlock config
general {
hide_cursor = true
}
background {
monitor =
path = $HOME/.config/backgrounds/satellite.jpg
blur_passes = 3
color = $base
}
# Labels: $TIME (font_size 90), date via cmd[update:43200000], $FPRINTPROMPT
# image: user avatar
# input-field: standard config
Stack trace (most recent crash, 2026-04-07)
The crashing thread calls abort() from within hyprlock, going through libstdc++ — indicating std::terminate (unhandled C++ exception). Multiple worker threads are idle inside libgallium.
Crashing thread (57102):
#0 libc.so.6: __kernel_vsyscall
#1 libc.so.6: raise
#2 libc.so.6: abort
#3 /usr/bin/hyprlock + 0x15c7c
#4 libstdc++.so.6 + 0xe55a4
#5 libc.so.6: clone3
#6 libc.so.6
Main thread (57088) — blocked on pthread_cond_clockwait:
#3 libc.so.6: pthread_cond_clockwait
#4 /usr/bin/hyprlock + 0x6a53a
#5 /usr/bin/hyprlock + 0x2478b
AsyncResourceGatherer thread (57100):
#3 libc.so.6: pthread_cond_clockwait
#4 libhyprgraphics.so.4: CAsyncResourceGatherer::asyncAssetSpinLock()
6 threads idle in libgallium-26.0.4 (pthread_cond_wait)
1 thread in libpangoft2 (g_async_queue_pop)
1 thread in hyprlock + 0x47ec1 (condition_variable::wait)
1 thread in hyprlock + 0x6b73e (pthread_cond_clockwait)
Relation to other issues
This looks very similar to #856, which was addressed in PR #858 (remove dmabuf listeners after screencopy). Since I'm on v0.9.3, I already have that fix, but crashes persist. This may be a separate race condition in the same area, possibly specific to Intel Arc's gallium driver.
Bug description
hyprlock crashes with SIGABRT while sitting idle on the lock screen. It's launched by hypridle, and when I return I see "your lock screen app has died". No user interaction triggers the crash — it happens while the lock screen is displayed and idle.
This has been recurring since October 2025. I have 22 coredumps (mix of SIGABRT and SIGSEGV) across multiple hyprlock/Mesa versions.
Environment
PAM config
PAM config is complete with auth, account, and session — this is not the PAM issue from #953.
hyprlock config
Stack trace (most recent crash, 2026-04-07)
The crashing thread calls
abort()from within hyprlock, going throughlibstdc++— indicatingstd::terminate(unhandled C++ exception). Multiple worker threads are idle insidelibgallium.Relation to other issues
This looks very similar to #856, which was addressed in PR #858 (remove dmabuf listeners after screencopy). Since I'm on v0.9.3, I already have that fix, but crashes persist. This may be a separate race condition in the same area, possibly specific to Intel Arc's gallium driver.