SIGABRT on launch when used as Omarchy screensaver (v0.3.1)

[binbot]

ttfx 0.3.1 crashes with SIGABRT immediately on launch when invoked as the Omarchy screensaver.

Command:

ttfx -i 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

The input file is a 1.5 KiB ASCII art file. The crash is a deliberate abort() from within ttfx's own code (coredump frame #3 at offset 0xcc30a). No debug symbols are published, so the exact failing function can't be determined from the coredump alone.

Reproducible: appears to crash every time on this machine.

Environment:

• Arch Linux (Omarchy 4.0.0 Quattro), kernel 7.1.8-arch1-Watanare-T2-2-t2
• ttfx installed from omarchy/ttfx 0.3.1-1

Systemd coredump info:
PID 1158623, Signal SIGABRT (SI_TKILL), Timestamp 2026-08-18 09:50:19 EDT

---

Filed by big-pickle via opencode.

[lvkz]

Datapoint suggesting this is the same bug as #10 (fixed in v0.3.2), not a separate launch crash.

I hit the identical failure on ttfx 0.3.1-1 (Arch/Omarchy, same screensaver invocation): same SIGABRT/SI_TKILL, and the coredump backtrace shares your frame #3 offset (ttfx + 0xcc30a directly above abort()). The panic string recovered verbatim from the core:

thread 'main' (3330675) panicked at library/std/src/io/stdio.rs:1166:9:
failed printing to stderr: Input/output error (os error 5)

That's the dead-output-tty panic from #10: frame write hits EIO when the pty master goes away, the eprintln! reporting it fails too, and the panic-in-panic aborts. In my case ttfx rendered fine for ~2.5 minutes and died the exact second omarchy-system-lock tore down the screensaver terminal — so "on launch" vs. "at teardown" is just a matter of when the hosting pty dies in your setup, not a different mechanism.

Verification that v0.3.2 fixes it: using the pty-master-close repro from #10 (fork on a pty with the exact Omarchy screensaver arguments, render ~1s, SIGHUP ignored, close the master):

• 0.3.1-1: SIGABRT, reproducibly
• 0.3.2-1: exit 0, 5/5 runs, no core dumped

v0.3.2 is already published in the Omarchy stable repo (pkgs.omarchy.org/stable/x86_64), so a plain system update picks it up — worth confirming whether the crash survives an upgrade to 0.3.2 on your machine; if it does, that would be a genuinely new bug.

[omarchybot]

Already fixed in v0.3.2. This is #10 arriving through the screensaver's respawn loop, not a separate launch crash.

Reproduced on ttfx 0.3.1-1 with your exact argument list, on a pty whose master is closed out from under it: SIGABRT/SI_TKILL every time, frame #3 at ttfx + 0xcc30a — the same offset as your coredump — and this recovered from the core:

thread 'main' panicked at library/std/src/io/stdio.rs:1166:9:
failed printing to stderr: Input/output error (os error 5)

The frame write fails with EIO once the terminal is gone, the eprintln! reporting it fails for the same reason, and panic = "abort" turns that panic-in-panic into the SIGABRT. "Immediately on launch" fits: omarchy-screensaver restarts ttfx in a while true loop, so a fresh process can start against a pty that is already dead and die on its first write. Whether you see it at startup or after minutes of rendering is only a question of when the hosting terminal dies.

The fix is 7b612c7 ("Print without dying when the stream is gone") and 9edd376 ("End the run when the terminal goes away"), released in v0.3.2 on 2026-08-17 — the day before this report. Same reproduction against 0.3.2-1: no abort and no core dump, 6 of 6 runs, against 6 of 6 aborts on 0.3.1-1.

ttfx 0.3.2-1 is in the Omarchy stable repo, so a system update picks it up. If the SIGABRT survives the upgrade, that is a new bug — worth reopening with a fresh coredumpctl info.