blob: 57e746220768725f56ded91f953d5629b10e2cc8 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
crash: uncaught std::bad_variant_access in Layout::CAlgorithm::layoutMsg on `layoutmsg mfact` (v0.55.4, also v0.54.1)
### Hyprland Version
v0.55.4, commit a0136d8c04687bb36eb8a28eb9d1ff92aea99704 (Arch package 0.55.4-1). The same crash hit v0.54.1 (commit 4b07770b) on 2026-03-07. Both crash reports are attached.
### Bug or Regression?
It's a bug: the same backtrace appears on v0.54.1 and v0.55.4.
### Description
Hyprland segfaults when a `hyprctl dispatch layoutmsg mfact -0.05` arrives. The backtrace shows an uncaught `std::bad_variant_access` in the layout message path:
```
std::__throw_bad_variant_access(unsigned int)
Layout::CAlgorithm::layoutMsg(std::basic_string_view<...> const&)
Layout::CSpace::layoutMsg(...)
Layout::CLayoutManager::layoutMsg(...)
Config::Actions::layoutMessage(...)
```
The active layout was master, and the identical mfact dispatch had worked seconds earlier in the same session. Related edge cases reply gracefully instead of crashing, so it looks like one mfact path is missing a variant guard:
- `layoutmsg mfact` with no focused window replies "mfact -> no window"
- master-only messages sent while in monocle reply "Unknown monocle layoutmsg: swapwithmaster"
### How to reproduce
I don't have a deterministic reproducer. Both crashes came from a resize keybind that dispatches `layoutmsg mfact -0.05` (or `0.05`). What the session log shows in the minutes before today's crash:
1. `general:layout` toggled between master and monocle several times during the session (long-lived session, 9 days).
2. Two windows closed shortly before the crash. The log shows "On closed window, new focused candidate is [Window nullptr]".
3. `togglefloating` dispatched twice.
4. The mfact keybind fired and Hyprland segfaulted.
My guess from the outside: per-workspace layout state (CSpace) ends up holding a different variant alternative than the one the active layout name implies. The mfact handler then does an unchecked `std::get`.
### Crash reports
Attached: today's report (v0.55.4) and the 2026-03-07 report (v0.54.1) with the identical backtrace through `Layout::CAlgorithm::layoutMsg`.
System: Arch Linux, kernel 6.18.25-lts. GPU: AMD Strix Halo (Radeon 8060S). No plugins loaded.
|