[Bug] SIGSEGV in CImageDescription::id() on wake - weak pointer race condition

[fredteumer]

System Info

• Hyprland: 0.53.0-2 (commit ea444c35)
• Aquamarine: 0.10.0-2
• Hyprutils: 0.11.0-1
• Kernel: 6.18.3-arch1-1
• GPU: AMD Radeon 880M (primary), NVIDIA RTX 5070 Ti Mobile

Bug Description

Hyprland crashes with SIGSEGV during monitor hotplug events on wake from suspend. This is a regression that persists despite the fix in commit 5faa66d ("protocols/cm: fix CColorManagementSurface m_imageDescription init").

Reproduction

1. Connect external monitor
2. Suspend system
3. Wake system
4. Crash occurs during connector scan/hotplug

Crash Analysis

Stack trace (consistent across all crashes):
#4 | NColorManagement::CImageDescription::id() const
#5 | CColorManagementSurface::imageDescription()

Log context shows hotplug event:
drm: Got a hotplug event for /dev/dri/card1
drm: Scanning connectors for /dev/dri/card1

Root Cause Analysis

The issue is that PImageDescription is defined as a weak pointer:

  // src/protocols/types/ColorManagement.hpp
  using PImageDescription = WP<const CImageDescription>;

In CColorManagementSurface, m_imageDescription is this weak pointer type. During hotplug:

1. CImageDescription objects are destroyed as resources are cleaned up
2. CColorManagementSurface still holds a weak pointer to the destroyed object
3. imageDescription() dereferences without checking validity: return m_imageDescription->value();
4. The underlying object is gone → this pointer is garbage → crash in id()

The Dec 27 fix (5faa66d) only initializes m_imageDescription in the constructor. It doesn't prevent the weak pointer from becoming dangling when the referenced object is destroyed during hotplug.

Suggested Fix

Either change PImageDescription to use SP (shared pointer), or lock the weak pointer before dereferencing:

const SImageDescription& CColorManagementSurface::imageDescription() {
      auto locked = m_imageDescription.lock();
      if (!locked) {
          LOGM(WARN, "m_imageDescription expired, using default");
          m_imageDescription = DEFAULT_IMAGE_DESCRIPTION;
          return DEFAULT_IMAGE_DESCRIPTION.lock()->value();

      }
      return locked->value();
  }

Related

• Previous discussion: Turning off monitor crash Hyprland in 0.53 #12758 (closed, requested debug stacktrace)
• Related: Chrome with color management stuff enabled crashes when moved between monitors while trying to destroy a `wp_image_description_v1` #11843, Washed out colors after resume from hibernation with monitor cm hdr #9724

Attachments

See attached crash reports with full backtraces and log context.

hyprlandCrashReport1205.txt
hyprlandCrashReport1211.txt

[areeh]

I am also getting a repeatable crash on NColorManagement::CImageDescription::id() on wake from suspend with external monitors, so feel free to ping me if you need more information

[UjinT34]

Does this happen on git?
Does this happen with #12812

Crash reports without a debug build aren't very helpful. And for this particular issue might not be relevant at all because the crash happens when a nullptr description is accessed and the bug is somewhere else where the description wasn't initialised/was set incorrectly.

[areeh]

The simplest repro I could find was hotplug my thunderbolt dock, then launch firefox.
I ran this after just altering

hyprland.url = "github:hyprwm/Hyprland";
hyprland.inputs.nixpkgs.follows = "nixpkgs";

in my flake.nix

github:hyprwm/Hyprland?ref=v0.53.1 crash
github:hyprwm/Hyprland no crash
github:hyprwm/Hyprland?rev=fe15dcd0e40f4aae959e016faa89c98791273350 no crash

[UjinT34]

github:hyprwm/Hyprland?rev=fe15dcd0e40f4aae959e016faa89c98791273350 no crash

that means it's fixed on git

[fredteumer]

github:hyprwm/Hyprland?rev=fe15dcd0e40f4aae959e016faa89c98791273350 no crash

that means it's fixed on git

After an install of hyprland-git i can confirm that this is fixed there. Should be able to close this out when this commit is upstreamed into hyprland main.

[fredteumer]

I'm testing hyprland-git this AM and will write back to see if it's fixed.

[danmaxis]

I think I had this issue too or very similar at least. I asked Claude to write a good report on it.

Hyprland Crash During System Suspend - Color Management SIGABRT

Bug Description

Hyprland crashes with SIGABRT during system suspend. The crash occurs in the color management subsystem (NColorManagement::CImageDescription::id()) immediately after the NVIDIA suspend service completes. This results in a complete session failure and prevents the system from entering suspend mode.

System Information

Component	Version
Hyprland	0.53.1 (commit ab1d80f)
Kernel	6.18.6-2-cachyos (PREEMPT_DYNAMIC)
Distribution	CachyOS Linux (rolling)
GPU	NVIDIA GeForce RTX 3060 Laptop GPU
NVIDIA Driver	590.48.01
Aquamarine	0.10.0
Hyprgraphics	0.5.0
Hyprutils	0.11.0
Hyprcursor	0.1.13
Hyprlang	0.6.8

ABI String: ab1d80f3d6aebd57a0971b53a1993b1c1dfe0b09_aq_0.10_hu_0.11_hg_0.5_hc_0.1_hlg_0.6

Steps to Reproduce

1. Run Hyprland session with NVIDIA GPU
2. Lock the session or leave idle
3. Allow system to enter suspend (via lid close, idle timeout, or manual suspend)
4. Observe crash during suspend transition

Expected Behavior

Hyprland should gracefully handle the suspend transition and allow the system to enter sleep mode.

Actual Behavior

Hyprland crashes with SIGABRT during the suspend process, specifically after nvidia-suspend.service completes but before the system enters sleep. This causes:

1. Complete session failure (all desktop services crash)
2. System fails to enter suspend ("Device or resource busy")
3. Hyprland threads become stuck in drm_release, blocking process freezing
4. System eventually resumes instead of sleeping

Timeline of Events

19:03:42 - systemd-logind: "The system will suspend now!"
19:03:42 - NVIDIA suspend service started
19:03:44 - NVIDIA suspend service completed successfully
19:03:44 - systemd-sleep: "Performing sleep operation 'suspend'..."
19:03:44 - kernel: PM: suspend entry (deep)
19:03:44 - Hyprland (PID 2107) terminated with SIGABRT
19:03:45 - Core dump generated
19:03:45 - Cascade failure of desktop services (xdg-desktop-portal, kded6, etc.)
19:04:07 - kernel: "Freezing user space processes failed" (7 tasks refusing to freeze)
19:04:27 - systemd-sleep: "Failed to put system to sleep. Device or resource busy"
19:04:28 - Suspend failed, system resumed

Stack Trace

Stack trace of thread 2107 (main):
#0  0x00007f3752aaa0fb pthread_kill (libc.so.6 + 0xaa0fb)
#1  0x00007f3752a447c8 raise (libc.so.6 + 0x447c8)
#2  0x00007f3752a2560d abort (libc.so.6 + 0x2560d)
#3  0x000055dc7e922140 n/a (/usr/bin/Hyprland + 0x271140)
#4  0x00007f3752a44900 n/a (libc.so.6 + 0x44900)
#5  0x000055dc7edde034 _ZNK16NColorManagement17CImageDescription2idEv (/usr/bin/Hyprland + 0x72d034)
#6  0x000055dc7ec2d14b n/a (/usr/bin/Hyprland + 0x57c14b)
#7  0x000055dc7eec7b98 n/a (/usr/bin/Hyprland + 0x816b98)
#8  0x00007f3752c532ee n/a (libffi.so.8 + 0x82ee)
#9  0x00007f3752c4f9f8 n/a (libffi.so.8 + 0x49f8)
#10 0x00007f3752c526ce ffi_call (libffi.so.8 + 0x76ce)
#11 0x00007f375394d220 n/a (libwayland-server.so.0 + 0x6220)
#12 0x00007f3753953134 n/a (libwayland-server.so.0 + 0xc134)
#13 0x00007f3753951642 wl_event_loop_dispatch (libwayland-server.so.0 + 0xa642)
#14 0x00007f3753953777 wl_display_run (libwayland-server.so.0 + 0xc777)
#15 0x000055dc7eba7f54 _ZN17CEventLoopManager9enterLoopEv (/usr/bin/Hyprland + 0x4f6f54)
#16 0x000055dc7e8accd7 main (/usr/bin/Hyprland + 0x1fbcd7)
#17 0x00007f3752a27b8b n/a (libc.so.6 + 0x27b8b)
#18 0x00007f3752a27c4b __libc_start_main (libc.so.6 + 0x27c4b)
#19 0x000055dc7e90c985 _start (/usr/bin/Hyprland + 0x25b985)

Additional Thread Stack Traces

Thread 2112 (Hyprgraphics async resource gatherer):

#0  0x00007f3752ab0872 n/a (libc.so.6 + 0xb0872)
#1  0x00007f3752aa4248 n/a (libc.so.6 + 0xa4248)
#2  0x00007f3752aa49a3 n/a (libc.so.6 + 0xa49a3)
#3  0x00007f3752aa7a29 pthread_cond_clockwait (libc.so.6 + 0xa7a29)
#4  0x00007f37539f85dd _ZN12Hyprgraphics22CAsyncResourceGatherer18asyncAssetSpinLockEv (libhyprgraphics.so.4 + 0x235dd)
#5  0x00007f3752f002f4 execute_native_thread_routine (libstdc++.so.6 + 0x1002f4)

Threads 2122, 2123, 2130, 2131 (Mesa/Gallium threads):

#4  0x00007f3749fa7ffe n/a (libgallium-25.3.3-arch1.5.so + 0x7a7ffe)
#5  0x00007f3749f3ad1d n/a (libgallium-25.3.3-arch1.5.so + 0x73ad1d)
#6  0x00007f3749fa7f2c n/a (libgallium-25.3.3-arch1.5.so + 0x7a7f2c)

Kernel Messages During Freeze Failure

Freezing user space processes failed after 20.000 seconds (7 tasks refusing to freeze, wq_busy=0):
task:Hyprland        state:D stack:0     pid:2112  tgid:2107  ppid:2082   task_flags:0x40044c flags:0x00080003
 drm_release+0x3c/0x130

Additional Context

• The system had $SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 set, which systemd warns against
• The crash also caused hyprsunset to crash (SIGABRT) as a dependent process
• After the failed suspend, zen-browser also crashed (SIGSEGV)

Core Dump Information

PID: 2107 (Hyprland)
UID: 1000
Signal: 6 (ABRT)
Timestamp: Mon 2026-01-19 19:03:44 -03
Command Line: Hyprland --watchdog-fd 4
Storage: /var/lib/systemd/coredump/core.Hyprland.1000.425ff8060a0a4379aad555ffaadd7ad1.2107.1768860224000000.zst
Size on Disk: 10.3M

Possible Root Cause

The crash appears to originate from NColorManagement::CImageDescription::id() being called during the suspend transition when GPU resources may be in an inconsistent state after nvidia-suspend.service has already prepared the GPU for sleep. This suggests a race condition or missing state check in the color management code path during suspend.

Workaround

None known at this time. Potential mitigations to test:

• Disable color management features if configurable
• Manually stop Hyprland before suspend via a systemd hook
• Test with SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=1 (default)

Related Information

• NVIDIA driver suspend/resume services are involved in the timing
• Wayland protocol dispatch (wl_event_loop_dispatch) is active when crash occurs
• Multiple Mesa/Gallium threads are also present, suggesting mixed GPU usage

---

Report Generated: 2026-01-19
Coredump Available: Yes (coredumpctl info 2107)