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.
probably ttfx's problem but I thought i should share it here too
Reported by Rowdydangerous · filed Aug 23, 2026Closed upstream on 2026-08-26 by its own reporter Rowdydangerous. 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
System details
11th Gen Intel(R) Core(TM) i7-1165G7 z, Omarchy 4.0.0-1
What's wrong?
Bug Report: ttfx SIGABRT Crash
1. What crashed and what it was doing
- Program: ttfx (binary: /usr/bin/ttfx)
- PID: 250253
- Signal: SIGABRT (signal 6, SI_TKILL — abort from process context)
- Timestamp: Sat 2026-08-22 21:43:22 EDT (about 4 minutes before report)
- Command line: ttfx -i /home/rowdy/.config/omarchy/branding/screensaver.txt --frame-rate 120 --canvas-width 0 --canvas-height 0 --reuse-canvas --anchor-canvas c --anchor-text c --random-effect --no-eol --no-restore-cursor
- Was doing: Running as a screensaver with the specified branding config file, at 120 fps, with various canvas/effect options
2. Most likely mechanism
What the evidence proves:
- The process dumped core via abort() in libc.so.6
- Backtrace: #3 abort() → #2 raise() → #3 ttfx + 0xcc30a → many ttfx frames → __libc_start_main
- The abort() call originated from within ttfx code (offset 0xcc30a in the executable)
- No third-party shared libraries are implicated in the crash frames
- This is a one-off crash (single entry in coredumpctl list)
What is inferred:
- ttfx called abort() or assert() due to an internal condition failure
- The trigger may be related to the screensaver config file, the --frame-rate 120 setting, or specific runtime state
- Without debug symbols, the exact source location within ttfx cannot be pinpointed
Limits of evidence: The backtrace is partially unresolved (frames show ?? from libc, and ttfx offsets without symbol names). The crash shape is clear (abort path), but the root cause condition is unknown.
3. User data loss
- No persistent data loss expected from a SIGABRT — the process simply terminated
- The screensaver config at /home/rowdy/.config/omarchy/branding/screensaver.txt is untouched (mtime: 2026-08-16, predating crash by 6 days)
- No indication of file corruption or data loss from the crash itself
- The core dump at /var/lib/systemd/coredump/core.ttfx.1000.00e13995cccf49189720599cfc8cd3a5.250253.1787449402000000.zst (965K) is the only transient state lost
4. Recurrence likelihood and fix
- Likelihood: Possible if the trigger condition is reproducible (specific config, specific runtime state). This is a one-off crash so far, but without knowing the trigger, cannot rule out recurrence.
- What would avoid/fix it:
- Debug symbols for ttfx to identify the exact code path at offset 0xcc30a
- Running ttfx with verbose/strace output to capture the condition preceding abort()
- Testing with different screensaver config parameters
- Testing at different frame rates or with --random-effect disabled
Summary
ttfx crashed via abort() called from within the process itself. This is an internal bug in ttfx, not caused by resource exhaustion, OOM, or external signals. The crash is reproducible enough to investigate (core dump present, command line recorded) but the exact trigger requires debug symbols or additional runtime tracing.
Leave the system as found: Core dump is managed by systemd; no cleanup required beyond what's already in place.
View raw text
### System details 11th Gen Intel(R) Core(TM) i7-1165G7 z, Omarchy 4.0.0-1 ### What's wrong? Bug Report: ttfx SIGABRT Crash 1. What crashed and what it was doing - Program: ttfx (binary: /usr/bin/ttfx) - PID: 250253 - Signal: SIGABRT (signal 6, SI_TKILL — abort from process context) - Timestamp: Sat 2026-08-22 21:43:22 EDT (about 4 minutes before report) - Command line: ttfx -i /home/rowdy/.config/omarchy/branding/screensaver.txt --frame-rate 120 --canvas-width 0 --canvas-height 0 --reuse-canvas --anchor-canvas c --anchor-text c --random-effect --no-eol --no-restore-cursor - Was doing: Running as a screensaver with the specified branding config file, at 120 fps, with various canvas/effect options 2. Most likely mechanism What the evidence proves: - The process dumped core via abort() in libc.so.6 - Backtrace: #3 abort() → #2 raise() → #3 ttfx + 0xcc30a → many ttfx frames → __libc_start_main - The abort() call originated from within ttfx code (offset 0xcc30a in the executable) - No third-party shared libraries are implicated in the crash frames - This is a one-off crash (single entry in coredumpctl list) What is inferred: - ttfx called abort() or assert() due to an internal condition failure - The trigger may be related to the screensaver config file, the --frame-rate 120 setting, or specific runtime state - Without debug symbols, the exact source location within ttfx cannot be pinpointed Limits of evidence: The backtrace is partially unresolved (frames show ?? from libc, and ttfx offsets without symbol names). The crash shape is clear (abort path), but the root cause condition is unknown. 3. User data loss - No persistent data loss expected from a SIGABRT — the process simply terminated - The screensaver config at /home/rowdy/.config/omarchy/branding/screensaver.txt is untouched (mtime: 2026-08-16, predating crash by 6 days) - No indication of file corruption or data loss from the crash itself - The core dump at /var/lib/systemd/coredump/core.ttfx.1000.00e13995cccf49189720599cfc8cd3a5.250253.1787449402000000.zst (965K) is the only transient state lost 4. Recurrence likelihood and fix - Likelihood: Possible if the trigger condition is reproducible (specific config, specific runtime state). This is a one-off crash so far, but without knowing the trigger, cannot rule out recurrence. - What would avoid/fix it: - Debug symbols for ttfx to identify the exact code path at offset 0xcc30a - Running ttfx with verbose/strace output to capture the condition preceding abort() - Testing with different screensaver config parameters - Testing at different frame rates or with --random-effect disabled Summary ttfx crashed via abort() called from within the process itself. This is an internal bug in ttfx, not caused by resource exhaustion, OOM, or external signals. The crash is reproducible enough to investigate (core dump present, command line recorded) but the exact trigger requires debug symbols or additional runtime tracing. Leave the system as found: Core dump is managed by systemd; no cleanup required beyond what's already in place.
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.