Crashed on Framework Desktop due to oom

[sluongng]

System Info and Hyprland Version

System/Version info

Crashing process:
Hyprland 0.54.1 built from branch v0.54.1 at commit 4b07770b9ef1cceb2e6f56d33538aaffb9186b9c.

Current installed packages after same-day update:
hyprland 0.54.2-1.1
hyprutils 0.11.0-1.1
aquamarine 0.10.0-2.1
hyprlang 0.6.8-1.1
hyprcursor 0.1.13-3.1
hyprgraphics 0.5.0-1.1
hyprwayland-scanner 0.4.5-1.1

Kernel:
6.19.6-2-cachyos

GPU:
AMD Strix Halo [1002:1586]

Monitor:
HDMI-A-1 Samsung Odyssey G70B 3840x2160

Backend:
drm

Notable effective config:
misc:vrr = 0
render:direct_scanout = 0

Description

Hyprland crashed unexpectedly during normal desktop use on an AMD Strix Halo iGPU system.

The strongest signal in the journal is that the kernel logged:

amdgpu: [drm] *ERROR* Not enough memory for command submission!

immediately before Hyprland aborted.

The confusing part is that the crash reporter then appears to fail while handling the crash:

terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot make canonical path: No such file or directory [/proc/self/exe]

coredumpctl also shows frames in /usr/bin/Hyprland (deleted). The machine had upgraded from 0.54.1-1.1 to 0.54.2-1.1 earlier the same day, so I think the /proc/self/exe failure is likely secondary crash-reporting fallout from a long-lived old binary, not necessarily the original trigger.

I checked the upstream v0.54.1...v0.54.2 diff before filing. I did not see any crash-reporter changes, OpenGL/renderer changes, or obvious Aquamarine/DRM changes that look like a direct fix for this crash signature. The only nearby fixes in 0.54.2 were:

• layout: fix crash on monitor reconnect due to stale workspace state
• protocols/sessionLock: fix crash when monitor is gone during lock surface creation
• screencopy: fix minor crash
• screenshare: improve destroy logic of objects

None of those looked like a clear match for this event.

I also checked the Bugs - Crashes discussions category for related reports. I found discussions that look adjacent but still not like an exact duplicate:

• #13269 AMD Strix iGPU SIGABRT after phantom hotplug events. Similar because it is also an AMD Strix/Aquamarine crash discussion and also lands in SIGABRT, but that report points to a connector rescan / GL reset path with a full renderer backtrace.
• #12884 wake-from-idle / external-monitor crash discussion. Similar because it involves display-state churn and Hyprland --watchdog-fd 4, but the backtrace is different and centered around surface commit / DPMS behavior.
• #13569 crash after Hyprlock login. Similar only in the broad sense of post-lock-session instability; the captured crash there is SIGSEGV, not this amdgpu + crash-reporter failure sequence.

I did not find a discussion with the specific combination of:

• amdgpu: [drm] *ERROR* Not enough memory for command submission!
• crash report truncated at Backtrace:
• filesystem error: cannot make canonical path ... [/proc/self/exe]

Expected behavior

Hyprland should not abort here.

If the compositor is reacting to a kernel / GPU-side failure, the crash report should still preserve the primary failure instead of failing in crash reporting on /proc/self/exe.

Actual behavior

Observed sequence:

1. Several unrelated container memcg OOM kills in the system journal.
2. Kernel logs amdgpu: [drm] *ERROR* Not enough memory for command submission!
3. Hyprland crashes.
4. Crash reporting itself aborts with filesystem_error on /proc/self/exe.
5. The generated Hyprland crash report is truncated at Backtrace:.

Additional info & File uploads

hyprlandCrashReport5409.txt
hyprctl-systeminfo.txt
journal-2026-03-11-160448-160451.txt
coredumpctl-info-5409.txt

[sluongng]

The details above were collected and generated with the help of a coding agent. But I did review and edit the contents manually before posting. I will also be replying to questions directly if y'all have any.

This is probably my 2nd-3rd crash in the last month. All have similar issues.