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: recurring crash in QML incubation (QQmlIncubatorPrivate::incubate)
Reported by pablo332eci · filed Oct 7, 2026Closed upstream on 2026-10-07 by its own reporter pablo332eci. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Crash summary
Process: quickshell (PID 68784), the Omarchy Wayland shell
Signal: SIGSEGV at Wed 2026-10-07 03:49:28 -03
`si_code`: SI_TKILL
What happened
The quickshell process dumped core with a segmentation fault. The crash occurs in Qt6's QML incubation system during QQuickRepeater::setModel and property binding writes.
Evidence
| Evidence | Detail |
|---|---|
| Timestamp | Wed 2026-10-07 03:49:28 -03 |
| Command line | quickshell -n -p /usr/share/omarchy/shell |
| Executable | /usr/bin/quickshell |
| Core dump | Present, 79.4M at /var/lib/systemd/coredump/ |
| Signal code | SI_TKILL (thread-to-thread kill) |
| Recurring pattern | 3 quickshell SIGSEGVs in ~24h: Tue Oct 6 03:54:08, Tue Oct 6 13:52:23, Wed Oct 7 03:49:30 |
| Memory | 7.9Gi free — no OOM kill |
| Freeze pattern | Crash cycles through QQmlBinding::slowWrite/update/emitNotify (~frames 14-37), then QCoreApplication::exec() |
Stack trace (symbolized)
#0 0x000078870f89a17c in __libc_start_main () from /usr/bin/../lib/libc.so.6
#1 0x0000641563f1f085 in ?? () (quickshell + 0xbe085)
#8 QQmlIncubatorPrivate::incubate () (libQt6Qml.so.6)
#11 QQuickRepeater::regenerate () (libQt6Quick.so.6)
#12 QQuickRepeater::setModel() (libQt6Quick.so.6)
#14 QQmlPropertyPrivate::write () (libQt6Qml.so.6)
#15 QQmlBinding::slowWrite () (libQt6Qml.so.6)
#19 QQmlNotifier::emitNotify () (libQt6Qml.so.6)
#41 QObject::~QObject () (libQt6Core.so.6)
#44 QCoreApplication::notifyInternal2 () (libQt6Core.so.6)
#52 QCoreApplication::exec () (libQt6Core.so.6)System
- Omarchy version: 4.0.4-1
- Distribution: Arch Linux
- Free memory: 7.9Gi out of 31Gi
Expected
The shell should remain running without SIGSEGV. The QML incubation/QQuickRepeater model-setting code path should not trigger a segmentation fault.
Diagnostics
coredumpctl info 68784— full info presentcoredumpctl dump 68784— core extracted and symbolized with debuginfodfree -h— no resource exhaustionjournalctl— no OOM kill messages
This is a verified bug in Omarchy's sphere (the quickshell is Omarchy's own shell), with a reproducible crash pattern. Searching GitHub issues turned up no matching reports.
Filed by nemotron via opencode.
View raw text
## Crash summary **Process**: `quickshell` (PID 68784), the Omarchy Wayland shell **Signal**: SIGSEGV at `Wed 2026-10-07 03:49:28 -03` **`si_code`**: `SI_TKILL` ### What happened The quickshell process dumped core with a segmentation fault. The crash occurs in Qt6's QML incubation system during `QQuickRepeater::setModel` and property binding writes. ### Evidence | Evidence | Detail | |---|---| | **Timestamp** | Wed 2026-10-07 03:49:28 -03 | | **Command line** | `quickshell -n -p /usr/share/omarchy/shell` | | **Executable** | `/usr/bin/quickshell` | | **Core dump** | Present, 79.4M at `/var/lib/systemd/coredump/` | | **Signal code** | `SI_TKILL` (thread-to-thread kill) | | **Recurring pattern** | 3 quickshell SIGSEGVs in ~24h: Tue Oct 6 03:54:08, Tue Oct 6 13:52:23, Wed Oct 7 03:49:30 | | **Memory** | 7.9Gi free — no OOM kill | | **Freeze pattern** | Crash cycles through `QQmlBinding::slowWrite`/`update`/`emitNotify` (~frames 14-37), then `QCoreApplication::exec()` | ### Stack trace (symbolized) ``` #0 0x000078870f89a17c in __libc_start_main () from /usr/bin/../lib/libc.so.6 #1 0x0000641563f1f085 in ?? () (quickshell + 0xbe085) #8 QQmlIncubatorPrivate::incubate () (libQt6Qml.so.6) #11 QQuickRepeater::regenerate () (libQt6Quick.so.6) #12 QQuickRepeater::setModel() (libQt6Quick.so.6) #14 QQmlPropertyPrivate::write () (libQt6Qml.so.6) #15 QQmlBinding::slowWrite () (libQt6Qml.so.6) #19 QQmlNotifier::emitNotify () (libQt6Qml.so.6) #41 QObject::~QObject () (libQt6Core.so.6) #44 QCoreApplication::notifyInternal2 () (libQt6Core.so.6) #52 QCoreApplication::exec () (libQt6Core.so.6) ``` ### System - **Omarchy version**: 4.0.4-1 - **Distribution**: Arch Linux - **Free memory**: 7.9Gi out of 31Gi ### Expected The shell should remain running without SIGSEGV. The QML incubation/QQuickRepeater model-setting code path should not trigger a segmentation fault. ### Diagnostics - `coredumpctl info 68784` — full info present - `coredumpctl dump 68784` — core extracted and symbolized with debuginfod - `free -h` — no resource exhaustion - `journalctl` — no OOM kill messages This is a verified bug in Omarchy's sphere (the quickshell is Omarchy's own shell), with a reproducible crash pattern. Searching GitHub issues turned up no matching reports. > Filed by nemotron via opencode.
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.
No decision has been recorded yet.