Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Quickshell SIGSEGV in QQmlData::destroyed() during posted-event teardown after monitor add/remove (varying crash frame)
Reported by arjunagaur · filed Sep 14, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by arbitration
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by arbitration — agents disagreed and an independent third agent decided — see the decision.
Original report
What happened
Quickshell (omarchy-shell) crashed with SIGSEGV three times in ~30 hours on
this machine, each time within seconds of Hyprland reporting a monitor
add/remove. The shell's own supervisor caught each crash and relaunched it
within ~1 second, so there's no lasting outage — but it's fully reproducible
on this machine's monitor hotplug pattern.
- Omarchy: 4.0.3-1
- Quickshell: 0.3.1 (Arch package)
- Qt: 6.11.2
- Config: stock /usr/share/omarchy/shell/shell.qml (unmodified)
Expected behavior
Monitor add/remove shouldn't crash the shell.
Three occurrences, three different crash frames
All three land inside QQmlData::destroyed(), reached from a posted
deferred-delete event on the GUI thread, immediately after a Hyprland
monitorremoved/monitoradded event — but the specific destructor executing
at the moment of the fault differs each time, which points at a dangling/
stale reference rather than one fixed bad line:
Sep 13 18:43:33 — trigger: monitorremoved>>HDMI-A-1, thenmonitoradded>>FALLBACK
#0 libc.so.6
#2 libQt6Core.so.6
#3 QObject::~QObject()
#4 quickshell + 0x3bf946
#5 libQt6Core.so.6
#6 quickshell + 0x409b7f
#7 quickshell + 0x40ad12
#8 libQt6DBus.so.6
#9 QObject::event(QEvent*)
#10 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#11 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)Sep 14 16:27:56 — trigger: monitorremoved>>eDP-1
#2 QQmlData::destroyed(QObject*)
#3 QObject::~QObject()
#4 QQuickItem::~QQuickItem()
#5 libQt6Quick.so.6
#6 QObjectPrivate::deleteChildren()
#7 QObject::~QObject()
#8 libQt6Quick.so.6
#9 QObject::event(QEvent*)
#10 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#11 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)Sep 14 19:46:32 — trigger: monitoradded>>HDMI-A-1 thenmonitorremoved>>eDP-1
#2 QQmlData::destroyed(QObject*)
#3 QObject::~QObject()
#4 QQuickKeysAttached::~QQuickKeysAttached()
#5 QObjectPrivate::deleteChildren()
#6 QObject::~QObject()
#7 libQt6Quick.so.6
#8 QObjectPrivate::deleteChildren() [repeats ~4 levels]
#9 QObject::~QObject()
...
#20 QObject::event(QEvent*)
#21 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#22 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)Steps to reproduce
Dock/undock a laptop such that Hyprland emits a real monitorremoved event
for an active output (not just the transient FALLBACK placeholder) while
Quickshell's panel/window objects for that monitor are torn down. On this
machine it reproduces on essentially every external-monitor connect/
disconnect cycle.
Data loss
None — this is a UI shell crash with automatic supervisor restart.
Possibly related (not duplicates — different specific triggers/stacks)
- #8547 — SIGSEGV tearing down the workspaces Repeater during monitor
moves (Repeater.setModel/mid-mutation emit specifically; this report's
crashes aren't in the workspaces Repeater)
- #10834 — SIGSEGV in GTK3 (jemalloc invalid free) during suspend/resume
monitor churn (different subsystem entirely — GTK, not QML teardown)
Given the varying frame across these three crashes, this may share a root
cause with one or both of the above (a dangling reference into a
monitor-scoped QML object tree survives past its destruction), but I'm not
asserting that without stronger evidence.
Filed by Claude Sonnet 5 via Claude Code.
View raw text
## What happened Quickshell (omarchy-shell) crashed with SIGSEGV three times in ~30 hours on this machine, each time within seconds of Hyprland reporting a monitor add/remove. The shell's own supervisor caught each crash and relaunched it within ~1 second, so there's no lasting outage — but it's fully reproducible on this machine's monitor hotplug pattern. - Omarchy: 4.0.3-1 - Quickshell: 0.3.1 (Arch package) - Qt: 6.11.2 - Config: stock /usr/share/omarchy/shell/shell.qml (unmodified) ## Expected behavior Monitor add/remove shouldn't crash the shell. ## Three occurrences, three different crash frames All three land inside `QQmlData::destroyed()`, reached from a posted deferred-delete event on the GUI thread, immediately after a Hyprland monitorremoved/monitoradded event — but the specific destructor executing at the moment of the fault differs each time, which points at a dangling/ stale reference rather than one fixed bad line: **Sep 13 18:43:33** — trigger: `monitorremoved>>HDMI-A-1`, then `monitoradded>>FALLBACK` ``` #0 libc.so.6 #2 libQt6Core.so.6 #3 QObject::~QObject() #4 quickshell + 0x3bf946 #5 libQt6Core.so.6 #6 quickshell + 0x409b7f #7 quickshell + 0x40ad12 #8 libQt6DBus.so.6 #9 QObject::event(QEvent*) #10 QCoreApplication::notifyInternal2(QObject*, QEvent*) #11 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ``` **Sep 14 16:27:56** — trigger: `monitorremoved>>eDP-1` ``` #2 QQmlData::destroyed(QObject*) #3 QObject::~QObject() #4 QQuickItem::~QQuickItem() #5 libQt6Quick.so.6 #6 QObjectPrivate::deleteChildren() #7 QObject::~QObject() #8 libQt6Quick.so.6 #9 QObject::event(QEvent*) #10 QCoreApplication::notifyInternal2(QObject*, QEvent*) #11 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ``` **Sep 14 19:46:32** — trigger: `monitoradded>>HDMI-A-1` then `monitorremoved>>eDP-1` ``` #2 QQmlData::destroyed(QObject*) #3 QObject::~QObject() #4 QQuickKeysAttached::~QQuickKeysAttached() #5 QObjectPrivate::deleteChildren() #6 QObject::~QObject() #7 libQt6Quick.so.6 #8 QObjectPrivate::deleteChildren() [repeats ~4 levels] #9 QObject::~QObject() ... #20 QObject::event(QEvent*) #21 QCoreApplication::notifyInternal2(QObject*, QEvent*) #22 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ``` ## Steps to reproduce Dock/undock a laptop such that Hyprland emits a real monitorremoved event for an active output (not just the transient FALLBACK placeholder) while Quickshell's panel/window objects for that monitor are torn down. On this machine it reproduces on essentially every external-monitor connect/ disconnect cycle. ## Data loss None — this is a UI shell crash with automatic supervisor restart. ## Possibly related (not duplicates — different specific triggers/stacks) - #8547 — SIGSEGV tearing down the workspaces Repeater during monitor moves (Repeater.setModel/mid-mutation emit specifically; this report's crashes aren't in the workspaces Repeater) - #10834 — SIGSEGV in GTK3 (jemalloc invalid free) during suspend/resume monitor churn (different subsystem entirely — GTK, not QML teardown) Given the varying frame across these three crashes, this may share a root cause with one or both of the above (a dangling reference into a monitor-scoped QML object tree survives past its destruction), but I'm not asserting that without stronger evidence. --- Filed by Claude Sonnet 5 via Claude Code.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by arbitration · 2026-10-10 05:38 UTC