Repeated crashes after 0.57.0

[amannan-123]

Hyprland version

v0.57.0

Is this a regression?

Looks like a regression to me

What's the bug?

Hyprland 0.57.0 with general.layout = scrolling dies after normal use (~50 min). Session relaunches with --safe-mode.

Debug log repeatedly shows:
Fullscreen::CFullscreenController::isFullscreen:
window <title> doesn't have FS handler assinged. This should never happen
for many clients (Chrome, Cursor, Konsole, Chat, Dolphin, …). Log then stops abruptly mid-clipboard traffic; no Hyprland coredump this time (PID 2674).

Earlier crashes on the same machine/version left SEGVs with:
#0 CPointerConstraintController::release
#1 ScrollingFullscreenHandler::updateFullscreenFade
#2–3 ScrollingFullscreenHandler dtor
… → CCompositor::cleanup

Dual Intel monitors (eDP-1 + HDMI-A-1). Package: hyprland 0.57.0-1ppa2~1resolute1. Full log + prior stack attached.

Reproduction steps

Random.
Some zips are attached with logs etc. Those were made by Cursor BTW.

Attachments

hyprland-bug-20261102-121032.zip
hyprland-bug-2341423.zip
hyprland-bug-1935637.tar.gz

I acknowledge that:

• I have searched all (open and closed) discussions and issues and my problem is not there.

• I have read the Code of Conduct and agree to follow it.

• I wrote this request with my own hands, my own keyboard, and in my own words.

[vaxerski]

if ::cleanup is called that sounds like an exit, not a crash per se. Nothing here points to a real bug, one of the crashes at exit is already fixed with aq 0.16, and the log warnings are not crashes

[amannan-123]

Might be kernel related then as @Fel-2 said. It has crashed over 4 times now after upgrade.
If I need to enable more logs or something lemme know. I'll try to reproduce it again in my free time.
Thanks!

[Fel-2]

Same symptom here on 0.57.0 with two monitors on Intel graphics: random "resets" back into --safe-mode, sometimes minutes apart, sometimes an hour. No Hyprland coredump, no OOM kill, and the log just stops. I profiled it, and on my machine Hyprland isn't exiting or crashing. Its main thread gets stuck in the i915 kernel driver, and start-hyprland's watchdog kills it about a second later.

Setup

• Hyprland 0.57.0 (Arch package), aquamarine 0.15.1, mesa 26.2.6, kernel 7.2.11 (Arch)
• Intel UHD 770 (Alder Lake-S, 8086:4680) on i915. Two 1080p outputs on the iGPU: HDMI at 240Hz, DP at 60Hz.
• Started right after updating from 0.56.2 to 0.57.0 (mesa 26.2.5 → 26.2.6 in the same update). 0.56.2 ran fine on the same kernel for over a week.

What happens at each reset
A watcher polling Hyprland every 0.2s shows it healthy and answering IPC, then the main thread is runnable (state=R) for about 1s while IPC times out, then the PID is gone and start-hyprland relaunches it with --safe-mode. Same pattern in 4 of 4 captured resets.

Kernel + user stacks (perf record -e cpu-clock -g -p <Hyprland>, rolling buffer). In the final second before the kill, the main thread is at 100% CPU, and 181/181 samples end in the same i915 function:

i915_active_acquire_preallocate_barrier   [i915]   <- all samples here
__intel_context_do_pin_ww                 [i915]
eb_pin_engine                             [i915]
i915_gem_do_execbuffer                    [i915]
i915_gem_execbuffer2_ioctl                [i915]
drm_ioctl_kernel / drm_ioctl / __x64_sys_ioctl
ioctl                                     (libc)
... libgallium-26.2.6 (dri_create_fence_fd)
... libEGL_mesa
Render::GL::CEGLSync::create()
Render::GL::CHyprGLRenderer::endRender(...)
Render::IHyprRenderer::renderMonitor(...)
Monitor::CMonitorFrameScheduler::onFrame()
... Aquamarine::CBackend::dispatchIdle()
CEventLoopManager::enterLoop()

So the per-frame eglCreateSyncKHR (native fence) → mesa execbuffer submission never returns. i915 spins pinning the context, and the watchdog SIGKILLs Hyprland because it can't check in. That would explain "log stops abruptly, no coredump". It also explains why it looks like an exit rather than a crash: the process just gets killed.

Ruled out on my side: the second GPU (an idle NVIDIA card on nouveau; still resets with AQ_DRM_DEVICES set to the iGPU only), layer blur on the shell's surfaces, config errors (--verify-config ok), memory pressure, keybinds.

Workaround I'm testing: booting with the Intel GPU on the xe driver instead of i915 (i915.force_probe=!4680 xe.force_probe=4680), since the looping code is i915-only. Too early to call, but displays, 240Hz and rendering all work. Rolling back to 0.56.2 should also work. I suspect 0.57's renderer submits in a pattern that hits this i915 bug much more often, but the actual hang is in the kernel driver.

@amannan-123 if you can run perf record -e cpu-clock -g -p $(pgrep -x Hyprland) with kernel.perf_event_paranoid=1 until the next reset, it would show whether yours is the same i915 loop. The i915_active_acquire_preallocate_barrier frame is the giveaway. Happy to share more details.

[amannan-123]

Just crashed again on dwindle (on lock screen this time). Perf wasn't running unfortunately. Seems like we can't find the root cause based on current info. :(

[Fel-2]

On the lock screen there's no window layout involved but Hyprland is still rendering every frame, so that fits the i915 submission loop, not a layout bug.

To catch it without remembering to start perf, here's an always-on recorder that survives the reset (it keeps the last 5 min in 30 s chunks):

sudo apt install linux-tools-$(uname -r)        # perf on Ubuntu
sudo sysctl kernel.perf_event_paranoid=1         # until reboot
mkdir -p ~/hypr-perf
systemd-run --user --unit=hypr-perf bash -c 'while :; do p=$(pgrep -x Hyprland); [ -n "$p" ] && perf record -e cpu-clock -F 199 -g -m 64 --switch-output=30s --switch-max-files=10 -p $p -o ~/hypr-perf/hypr-$p.data; sleep 0.5; done'

After the next reset, open the newest file of the old PID:
perf report -i <file> --stdio --no-children --sort sym | head -30
If i915_active_acquire_preallocate_barrier tops the list, it's the same bug. Stop the recorder with systemctl --user stop hypr-perf.

[yostin-ramirez]

@Fel-2 on my setup, it has only happened about 4 or 5 times so far. From what I’ve noticed, it usually occurs when the PC is idle, maybe (i’m not sure) when hypridle is about to turn off my monitor. Instead of turning it off normally, hyprland resets into --safe-mode
To be honest, I'm not entirely sure how to gather proper debug info for this. When I open the crash report directory suggested by the safe-mode prompt, the file inside is completely empty. I'm not really sure where else to look for the logs or coredump in this case.

Idk if it’s hypridle related, but this is what i run in my hypridle.conf:

listener {
    timeout = 360
    on-timeout = hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'
    on-resume = hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })'
}

[LRitzdorf]

@yostin-ramirez I'm also getting crashes when enabling DPMS (on an Nvidia 1660 Ti), so I think we may be in the same boat. Weirdly, they stop if I set HYPRLAND_NO_RT=1, but I don't actually think this is RT-related? For each crash, dmesg reports a segfault in hyprland-dialog, then one in Hyprland itself about a second later. I am... confusion.

Anyway, I'd be curious whether sleep 1; hyprctl dispatch 'hl.dsp.dpms({ action = "toggle" })' crashes you as well, and whether setting HYPRLAND_NO_RT helps.

Update: bisected this back to 5b260fa, so yeah, it does indeed seem to be an RT thing. Wooooo.

[yostin-ramirez]

@LRitzdorf Ohhh yeah, we definitely have the exact same problem, and everything you said is right. sleep 1; hyprctl dispatch 'hl.dsp.dpms({ action = "toggle" })' doesn't crash for me (idk why), and HYPRLAND_NO_RT solved the issue for me too. So I'm keeping that env until it's fixed, thank you!

[tobias-haenel]

The kill comes from the kernel's realtime CPU limit, not the watchdog

Disclosure: I found this with AI assistance (Claude Code). The AI
wrote this summary and did all of the analysis. I only reproduced the
crash and ran the scripts it gave me. I'm posting it because it might
help explain the "log just stops, no coredump" resets in this thread.
you can go and delete it, if this doesn't help.

Setup

• Hyprland 0.57.0 (Arch 0.57.0-3), aquamarine 0.16.0, started via uwsm
• NVIDIA RTX 4070 Mobile (AD106M), nvidia-open 615.78.08, kernel
  7.2.14-arch1-1
• Laptop with the internal panel (eDP-1) disabled in the config, one
  external monitor on DP-1

Reproduction

1. Turn off the external monitor with its power button. DP-1
   disconnects and Hyprland falls back to the FALLBACK output.
2. Wait a few minutes, then move the mouse.
3. Hyprland disappears and start-hyprland restarts it in
   --safe-mode.

It happened 3 times in 3 tries. Input seems to be the trigger: on the
last try nothing happened for over 10 minutes, and Hyprland was killed
only once I moved the mouse. The earlier tries died 2 to 4 minutes
after the disconnect, and I may have touched the mouse or keyboard
then. So the stall probably happens when Hyprland renders or updates
the cursor on the FALLBACK output. The usual signs were all there: no
Hyprland coredump, no crash report, no OOM kill, the log stops mid-line,
and start-hyprland reports "Couldn't waitpid for hyprland: No child
processes".

What kills it

With gdb attached, the threads just vanish. No signal is caught and no
exit_group is called, which suggests SIGKILL. So I recorded every
SIGKILL on the system with
perf record -a -g -e signal:signal_generate --filter 'sig == 9'.
Hyprland sends the SIGKILL to itself, from kernel context:

Hyprland 14869: signal_generate sig=9 code=128 (SI_KERNEL) comm=Hyprland pid=14869
    __send_signal_locked
    send_signal_locked
    posix_cpu_timers_work
    task_work_run
    exit_to_user_mode_loop
    do_syscall_64
    entry_SYSCALL_64_after_hwframe
    ioctl                 (libc.so.6)
    [unknown]             (libnvidia-eglcore.so.615.78.08)

start-hyprland sent no signal at all.

posix_cpu_timers_work is the kernel enforcing a CPU-time rlimit. In
this case the limit is RLIMIT_RTTIME, because Hyprland's main thread
runs with realtime scheduling (it gets this via rtkit):

$ chrt -p $(pgrep -xo Hyprland)
current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK
current scheduling priority: 1

$ grep -i realtime /proc/$(pgrep -xo Hyprland)/limits
Max realtime timeout      150000               200000               us

The likely sequence is this. Input on the FALLBACK output causes
work on the GPU. The main thread gets stuck in an NVIDIA driver ioctl
and keeps running without blocking for more than 200 ms,
which is the hard limit. The kernel then kills the whole process with
SIGKILL. That would explain why there's never a coredump or a final log
line.

Why this might matter for this thread

The perf profile from the i915 users here shows the main thread at
100% CPU inside the GPU driver for about a second before the kill.
That's the same pattern, and the kill doesn't have to come from the
watchdog. If their Hyprland also runs as SCHED_RR, RLIMIT_RTTIME
is probably what kills it there too.

So I think two issues combine here:

1. The main thread can spin in the driver for hundreds of milliseconds:
   i915 for others in this thread, and for me nvidia on the fallback
   output, as soon as there is input.
2. Because of the realtime priority, that spin is fatal instead of
   only causing a stutter.

Workarounds that might help (not yet verified)

• Remove realtime scheduling from the main thread after startup:
  chrt -o -p 0 "$(pgrep -xo Hyprland)". Then RLIMIT_RTTIME no
  longer applies.
• In my case: use hyprctl dispatch dpms off instead of the power
  button, so that DP-1 never disconnects.

I still have the full perf output and the logs and can share them on
request.

[Fel-2]

This checks out on Intel too. On my Alder Lake box (i915, later xe) Hyprland's main thread is SCHED_RR prio 1 with Max realtime timeout 150000 / 200000 us. That reframes my earlier perf trace: the ~1s spent in i915_active_acquire_preallocate_barrier was probably a long but finite driver stall, not an infinite loop. The kill only lands when the ioctl returns, which matches your posix_cpu_timers_work → exit_to_user_mode_loop stack. It also explains a reset I got on xe today while RAM was tight: a reclaim stall over 200 ms trips the same limit.

One correction to the workaround: chrt -o -p 0 fails with "Operation not permitted" for a normal user, because it also tries to clear SCHED_RESET_ON_FORK, which needs privileges. Keeping the flag works:
chrt -o -R -p 0 "$(pgrep -xo Hyprland)"
To make it stick, I run it from autostart: hl.exec_cmd("sleep 2 && chrt -o -R -p 0 $(pgrep -xo Hyprland)"). Too early to report long-term results; I'll follow up.

If this holds, the real fix is on Hyprland's side: either not keep the main thread on SCHED_RR, or handle RLIMIT_RTTIME/SIGXCPU so a long GPU call doesn't become a SIGKILL. That would explain why NVIDIA and i915 users both see it on 0.57.

[Amaan1234567]

having similar crashes after upgrading to 0.57.0, system just crashes and opens in safe mode and its random, sometimes its after 30 minutes, sometimes after an hour

[amietn]

Same here. Crashed twice today

[idanycb]

Been having the crashes the moment I upgraded to Hyprland v0.57.0

My Setup

Hyprland 0.57.0 (Fedora 44, copr nett00n/hyprland: hyprland-0.57.0-5.fc44, aquamarine-0.16.0-1.fc44)
Kernel 7.2.15-200.fc44, Mesa 26.2.5
GPU: Intel TigerLake-H GT1 [UHD Graphics] (i915), renders and drives both screens
     (NVIDIA RTX 3050 Mobile present but unused by Hyprland)
Monitors: eDP-1 1920x1080@144.15, HDMI-A-1 1920x1080@120.00

I was playing around with Claude to reproduce the crash (We made a automated script to run and play through several youtube vids on Chrome on multiple monitors) and it indeed crashed.

4-real-crash-chrome-trace.txt

The Problem

• I was using Hyprland v0.56.2 before this and we found through the journal logs that rtkit granted realtime access to the latest version but apparently the previous version never got realtime cpu access since it requires CAP_SYS_NICE capability which my desktop session didn't have and it quietly failed with Hyprland running on normal priority.
• In the latest version, a fallback through rtkit was implemented. As previously mentioned rtkit has a maximum (RTTimeUSecMax, 200000 µs on Fedora). Hyprland itself does have a soft cap of 150ms on which it is to be reverted to Normal priority but in my case the main thread was stuck inside one long kernel call (most likely in the GPU driver). The soft-limit check never ran and past 200ms got a SIGKILL straight away.
• SIGKILL produces no core dump, never reaches Hyprland's crash handler, and leaves no log line. That's what made it notorious to find.
• Claude told me that the trigger was a long call inside the graphics driver on Hyprland's main thread.
  Fel-2's perf trace in the thread shows i915 (i915_active_acquire_preallocate_barrier)
  That's why it seems to be common on Intel i915 with several monitors, and with heavy video like Chrome or YouTube.

How I reproduced the crash

1. Check that Hyprland is on the rtkit route:
   grep realtime /proc/$(pgrep -x Hyprland)/limits
   "Max realtime timeout" should show 150000 / 200000.
2. Run:
   hyprctl eval '(function() local f = assert(io.open("/dev/zero", "rb")); local s = f:read(2147483648); f:close(); return #s end)()'
3. Hyprland dies immediately and start-hyprland restarts it in safe mode.

1-repro-stock-0.57-rtkit.txt
2-repro-stock-0.57-trace.txt

Reason
hyprctl eval ran Lua code inside Hyprland, on its main thread. The code opens /dev/zero, a "file" that only produces zeros, and reads 2 GB from it in a single call. Filling 2 GB of memory takes the kernel well over 200 ms. During that time Hyprland's main thread is inside the kernel the whole time: it neither sleeps nor returns to its own code. That artificially recreates what happens with a long GPU-driver call. The problem is that the kernel only checks the soft limits after the thread returns from the kernel to user space. A thread stuck in one long kernel call therefore gets SIGKILL directly and never sees SIGXCPU.

I also tested direct realtime via CAP_SYS_NICE, which sets no RLIMIT_RTTIME, and Hyprland survived the same /dev/zero stall, so only the rtkit fallback with its 200 ms limit is the culprit.

5-repro-direct-realtime-CAP_SYS_NICE.txt

Temporary Fix

• Hyprland actually provides its own switch to skip realtime entirely. The cost is slightly lower priority when the CPU is fully loaded.
• Just add export HYPRLAND_NO_RT=1 at the end of ~/.config/uwsm/env-hyprland
• Log out and log back in for the fix to work.
• You can check if it works by running
  chrt -p $(pgrep -x Hyprland)
• It should say SCHED_OTHER. If it says SCHED_RR, the setting didn't reach Hyprland.

This only applies to uwsm. People with different setups have to set the variable wherever the environment for start-hyprland comes from. I haven't tested other ways.
I tested using the same hyprctl eval command and it no longer crashes

3-repro-with-HYPRLAND_NO_RT.txt

[idanycb]

@amannan-123 Did you by chance try the chrt -o -R -p 0 workaround? Coz that might show the output mentioned in step 1 but cant reproduce the crash. Check chrt -p $(pgrep -xn Hyprland) - if it shows SCHED_OTHER then it checks out that you are already not running on rt. Also around 4-5gb of free RAM space is required for step 2 to work. If not you can try
hyprctl eval '(function() local f = assert(io.open("/dev/urandom", "rb")); local s = f:read(536870912); f:close(); return #s end)()'
It only needs 1gb. See if it reproduces the crash and restarts in safe mode. If not I need to check more about this issue. The workaround worked for me and I read other threads that discuss the same fix

[amannan-123]

chrt -p $(pgrep -xn Hyprland) gives:

pid 2372437's current scheduling policy: SCHED_OTHER|SCHED_RESET_ON_FORK
pid 2372437's current scheduling priority: 0
pid 2372437's current runtime parameter: 2800000

I guess my crash is different than yours since I'm not hitting the rt fallback.
I can'r reliably check workarounds if I can't reliably reproduce it.

[wabarTM]

Wow spending a hell lotta time typing all that just to be called a bot is crazy

Recently, land of the Hypr repo got enormous amounts of botted stars and a few bots answering in discussions, and you just happened to have similar formatting /shrug

BTW, rtkit is being dropped, so there is no need to dig into rt crashes

[nitin-dixit]

2. Run:
   hyprctl eval '(function() local f = assert(io.open("/dev/zero", "rb")); local s = f:read(2147483648); f:close(); return #s end)()'

This crashes my system too. I'm using noctalia v5.

[nitin-dixit]

Temporary Fix

• Hyprland actually provides its own switch to skip realtime entirely. The cost is slightly lower priority when the CPU is fully loaded.
• Just add export HYPRLAND_NO_RT=1 at the end of ~/.config/uwsm/env-hyprland
• Log out and log back in for the fix to work.
• You can check if it works by running
  chrt -p $(pgrep -x Hyprland)
• It should say SCHED_OTHER. If it says SCHED_RR, the setting didn't reach Hyprland.

This only applies to uwsm. People with different setups have to set the variable wherever the environment for start-hyprland comes from. I haven't tested other ways. I tested using the same hyprctl eval command and it no longer crashes

Thanks for this. So far so good on arch,hyprland with noctalia v5.

[bkrishnan]

After wondering for a week why my hyprland was crashing everytime I switched off and on my external HP monitor, I finally put my agent to work finding the root cause and a fix. My issue is solved. Below is Claude's summary if it helps anyone else:

Claude's summary:

Another confirmation of the RLIMIT_RTTIME kill, this time on nouveau with a DisplayPort monitor being power-cycled. Traced with bpftrace (no ptrace, so the timing isn't disturbed), in case it helps pin it down.

Setup: NixOS, Hyprland 0.57.1, aquamarine 0.16.0, kernel 6.18.60 and 6.18.62, iMac 13,2 with an NVIDIA GK104 on nouveau (aquamarine uses the legacy DRM path), HP E223 on DP-2. rtkit is installed.

Symptom: Switching the HP on while logged in kills Hyprland every time, about 120 ms after aquamarine logs drm: Connector DP-2 connected. There's no crash report, no core dump and no kernel segfault line, and the log tail is lost. start-hyprland restarts it in safe mode, which then dies on the monitor's next reconnect. Switching it on at the greeter is fine. 0.56.2 handled 58 of these power-ons from Sep 27 to Nov 6 without a crash.

What kills it: bpftrace on signal:signal_generate and kprobe:do_exit shows a SIGKILL that the process "sends to itself" from the kernel's CPU-timer check:

signal 9 -> tid 7420 (.Hyprland-wrapp) group 1 result 0, sent by pid 7420 tid 7420 (.Hyprland-wrapp)
        __send_signal_locked+604
        send_signal_locked+164
        posix_cpu_timers_work+388
        task_work_run+102
        exit_to_user_mode_loop+308
        do_syscall_64+601
        entry_SYSCALL_64_after_hwframe+119
do_exit code 9 (0x9) tid 7420 (.Hyprland-wrapp)   [then every other thread, code 9]

No SIGXCPU is generated beforehand. The main thread is SCHED_RR|SCHED_RESET_ON_FORK priority 1, granted by rtkit ([NInit::gainRealTime] Gained realtime scheduling via rtkit). Its limits show Max realtime timeout 150000 200000 us, while start-hyprland and the systemd user manager have no limit.

Why it overruns: When the HP comes back, the main thread probes the connector twice in a row: once in the hotplug scan, and again in drmModeGetConnector before SDRMConnector::connect(). On nouveau each probe takes about 110 ms (DDC/EDID over DP), so the thread spends roughly 220 ms in the kernel without sleeping. The limits are only checked on return to user space, and the hard limit is checked first. So the SIGXCPU handler that's supposed to drop realtime never gets a chance to run.

Supporting evidence:

• If a stall lands between 150 and 200 ms, Hyprland survives and demotes itself. In one session the first power-on logged Realtime budget exceeded (SIGXCPU), dropping realtime scheduling. That session then handled 15 more power-ons over two days without a crash, which is what originally made this look intermittent.
• With gdb attached as root, 3 power-ons didn't crash, because the ptrace stops reset the RT timer. After gdb detached, the next power-on in the same session crashed.
• A local build of aquamarine 0.16.0 with 082179b reverted (the invalidateFrame() added in connect()) still crashed, so that commit isn't the cause.

Workaround: HYPRLAND_NO_RT=1 in the session environment. The main thread then runs as SCHED_OTHER with no RTTIME limit, and the same power-on and DPMS-off cycles no longer crash, whether locked or unlocked.

It seems the hard limit needs headroom for synchronous connector probes on slow drivers, or the probes need to run off the realtime thread. Otherwise any monitor hotplug on hardware with slow DDC can trip it.

[wabarTM]

if only he knew this is fixed in 0572...

[bkrishnan]

Thanks, I'll confirm on 0.57.2 once nixpkgs has it.