[Crash] togglespecialworkspace can dereference null monitor during specialWorkspace slidevert animation

[derekszen]

Bug Description

Hyprland crashed while processing a hyprctl dispatch togglespecialworkspace scratchpad request. The coredump points to a null monitor pointer in CDesktopAnimationManager::startAnimation() while animating a special workspace out with the specialWorkspace slidevert animation.

This came from real crash data rather than a minimized synthetic repro. I worked around it locally by avoiding togglespecialworkspace, but the compositor should not segfault if a special workspace has lost/does not have a monitor pointer during close-out animation.

Before filing, I searched open issues and discussions for the exact terms togglespecialworkspace, specialWorkspace, DesktopAnimationManager, PMONITOR, null monitor, and slidevert. The closest related discussions I found were about orphaned/null-monitor workspace states or special scratchpad behavior, but not this togglespecialworkspace -> startAnimation() null monitor crash path.

Trigger / Reproduction Data

Observed trigger from the coredump/debug session:

/dispatch togglespecialworkspace scratchpad

Relevant local config uses Omarchy's default special workspace animation:

animation = specialWorkspace, 1, 3, easeOutQuint, slidevert

The crash happened immediately after a user service started and attempted to focus/open an Obsidian window that was on special:scratchpad:

2026-06-22 06:00:34 user service started
2026-06-22 06:00:40 Hyprland crashed

The crash report says Hyprland received SIGSEGV; coredumpctl records SIGABRT because Hyprland's crash handler aborted after handling the segfault.

Expected Behavior

togglespecialworkspace scratchpad should either close/show the special workspace or fail gracefully. If the workspace has no valid monitor, the animation should be skipped or should use a valid fallback monitor; Hyprland should not crash.

Observed Behavior

Hyprland crashed in the special workspace close-out path:

#5  CDesktopAnimationManager::startAnimation(...)
#6  CMonitor::setSpecialWorkspace(...)
#7  Config::Actions::toggleSpecial(...)
#14 CHyprCtl::getReply(...)

Source-level diagnosis from the coredump:

CHyprCtl request/readBuffer: "/dispatch togglespecialworkspace scratchpad"
Config::Actions::toggleSpecial:
  workspaceName = "special:scratchpad"
  workspaceID = -98
  requestedWorkspaceIsAlreadyOpen = true
CMonitor::setSpecialWorkspace:
  pWorkspace = null
  POLDSPECIAL = old special:scratchpad workspace
  calls startAnimation(m_activeSpecialWorkspace, ANIMATION_TYPE_OUT, false)
CDesktopAnimationManager::startAnimation:
  ANIMSTYLE = "slidevert"
  type = ANIMATION_TYPE_OUT
  PMONITOR = null

In v0.55.4, DesktopAnimationManager.cpp dereferences PMONITOR in the vertical-slide branch:

} else if (vert) {
    const auto YDISTANCE = (PMONITOR->m_size.y + *PWORKSPACEGAP) * (movePerc / 100.f);

I also checked current main; the same branch still dereferences PMONITOR for slidevert, and the fallback slide branch dereferences it for m_size.x too.

CMonitor::setSpecialWorkspace() calls into that animation when closing a currently active special workspace:

if (!pWorkspace) {
    if (m_activeSpecialWorkspace) {
        m_activeSpecialWorkspace->m_visible = false;
        g_pDesktopAnimationManager->startAnimation(m_activeSpecialWorkspace, CDesktopAnimationManager::ANIMATION_TYPE_OUT, false);

Proposed Fix

The compositor-side invariant seems to be the important part: startAnimation() should not assume ws->m_monitor.lock() succeeds for every workspace passed to it, especially during special workspace close-out / monitor transition states.

Potential fix directions:

1. In CMonitor::setSpecialWorkspace(), when closing the active special workspace, ensure the workspace being animated has a valid monitor/fallback monitor for the duration of the animation, likely the CMonitor instance currently closing it.
2. In CDesktopAnimationManager::startAnimation(), guard PMONITOR before all dimension-dependent animation branches (slide, slidevert, etc.). If it is null, skip/warp the animation state instead of dereferencing it.

A local user-space workaround is to avoid togglespecialworkspace and use a normal named workspace as a scratchpad, or disable the specialWorkspace slide animation. That avoids the trigger but does not fix the compositor crash condition.

Environment

Hyprland 0.55.4 built from branch v0.55.4 at commit a0136d8c04687bb36eb8a28eb9d1ff92aea99704 clean
Date: Thu Jun 11 17:10:04 2026
Tag: v0.55.4, commits: 7378

OS: Arch Linux
Kernel: 7.0.12-arch1-1
GPU: NVIDIA GB202 [GeForce RTX 5090 D]
Driver packages: nvidia-open-dkms 610.43.02-2, nvidia-utils 610.43.02-2

Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.1, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.12.0, system has 0.12.1

[vaxerski]

thanks! #15224