Repository navigation
Regression in 0.56: "workspace N silent" window rule applied to a toplevel created during an active tab drag corrupts layout state, SIGSEGV in CDwindleAlgorithm::resizeTarget #15856
Replies: 2 comments
|
Update: I traced the regression to a specific commit by source analysis. Faulty commit: 9d28438 "protocols/xdg-shell: add support for xdg interactive drags (#15343)", first released in v0.56.0. This matches my regression window exactly (0.55.x fine, first crash on the day I installed 0.56.0). Mechanism: Before this commit, After it, the sequence on tear-out is:
Related but distinct: #15789 / commit a269fd7 fix a stale Possible fixes, in increasing order of niceness:
|
|
I hit the same crash signature on v0.56.2 today, but I do not have a Chrome Environment:
Observed timeline:
The crash report says Hyprland received SIGSEGV. The coredump records the later crash-handler SIGABRT. The relevant frames match this discussion exactly: This was a real compositor crash rather than OOM or GPU reset: memory pressure was normal, no OOM event was logged, and the trace stays in the dwindle interactive resize path. Filed by GPT-5 via Codex. |
Uh oh!
There was an error while loading. Please reload this page.
Hyprland Version
Arch Linux, kernel 6.18.41-1-lts. GPU: Intel Arc A380 (DG2). Dwindle layout, Lua config.
Regression window: never happened on 0.55.x (0.55.4 and earlier, in daily use since May). First crash occurred the same day 0.56.0 was installed; reproduces on 0.56.1.
Bug or Regression Description
I run Chrome instances with custom classes (
--class=jup-chromeetc.) and had persistent window rules pinning them to workspaces:With such a rule active, tearing a tab out of a Chrome window (which creates a new toplevel while the toplevel drag is still active) breaks the compositor in stages:
hyprctl clients.On 0.55.x the same config and the same action were harmless (the torn-out window would just end up on the pinned workspace after the drag, with no layout corruption).
Removing the persistent
workspace N silentrules for these classes makes the whole chain (wrong placement, ghost window, crash) disappear. So the trigger is specifically: a window rule with a silent workspace move matching a toplevel that is created during an active xdg toplevel drag.Even with a "bad" config, the compositor presumably shouldn't end up with a corrupted layout tree and segfault. Either the workspace move should be deferred until the drag ends, or the drag/layout state should survive the move.
How to Reproduce
google-chrome(or a custom--class),workspace = "N silent"where N is not the current workspace.Crashes within one or two attempts for me.
Crash Report (backtrace)
Two identical crash reports from consecutive days, both:
Full crash reports below.
hyprlandCrashReport1852.txt
hyprlandCrashReport2390287.txt
All reactions