rtk-ai/rtk

panic/SIGABRT on Broken pipe while writing stdout

Open

#1,004 创建于 2026年4月3日

在 GitHub 查看
 (1 评论) (0 反应) (0 负责人)Rust (48,085 star) (2,914 fork)batch import
bugeffort-smallgood first issueresolved-pending-close

描述

Summary

rtk aborts with a Rust panic when stdout is closed (Broken pipe), producing SIGABRT + coredump instead of exiting gracefully.

Environment

  • OS: Arch Linux (x86_64)
  • rtk version: 0.31.0
  • Binary: /home/s3s/.local/bin/rtk
  • Build ID: cc06a1448d8bbdd786613878d0ec5dd3537f3ce9

What happened

On 2026-04-03 (CEST), multiple rtk invocations crashed (SIGABRT) and generated core dumps.

Observed commands at crash time:

  • rtk ls -la /mnt/datos/2brain-backend/scripts/deploy/
  • rtk git log --oneline --all --decorate -50
  • rtk git diff ae78d87^..ae78d87 --name-only (repeated)

systemd services were healthy (systemctl --failed and systemctl --user --failed both empty), so this is user-space process crash behavior in rtk.

Evidence

coredumpctl list rtk showed 5 crashes (all SIGABRT) on 2026-04-03.

From core dump strings (same pattern across all affected PIDs):

thread 'main' (...) panicked at /rustc/.../library/std/src/io/stdio.rs:1165:9:
failed printing to stdout: Broken pipe (os error 32)

I validated this message in multiple dumps (e.g. PIDs 30441, 42021, 490097, 491982, 492096).

Expected behavior

If stdout is closed by downstream consumer (EPIPE), rtk should terminate cleanly (or return non-zero) without panic/abort/coredump.

Actual behavior

rtk panics in std::io::stdio on write to stdout, then aborts and dumps core.

Notes

This looks like unhandled Broken pipe on output path. Handling EPIPE explicitly (or ignoring SIGPIPE semantics appropriately for CLI output writes) should avoid process aborts and coredumps in normal shell workflows.

贡献者指南

技术栈
rust
领域
cli
议题类型
bug
难度面向新贡献者的预计实现难度，1 表示很小改动，5 表示专家级工作。
2
预计时间有经验贡献者完成调查、实现、测试并准备 pull request 的粗略时间范围。
under 1 hour
活动状态议题当前的可参与程度：新鲜、活跃、陈旧、阻塞或等待维护者输入。
fresh
清晰度议题是否清楚说明期望改动、验收标准和下一步。
clear
前置要求
Basic Rust knowledgeUnderstanding of stdout and signal handling
新手友好度1-100 的估计分数，表示该议题对首次贡献者的友好程度。
85
研究方向
Investigate the main stdout output paths in rtk. The panic occurs in std::io::stdio::print to buffer, so handle `ErrorKind::BrokenPipe` by ignoring or silently exiting. Alternatively, set SIGPIPE to SIG DFL or ignore. Check if there's a custom writer or if using `writeln!` directly. Provide a patch that catches the broken pipe error.
panic/SIGABRT on Broken pipe while writing stdout · rtk-ai/rtk#1004 | Good First Issue