From 2a633d604a32e649d36e740fe8f94205de9301e2 Mon Sep 17 00:00:00 2001 From: dave Date: Tue, 31 Mar 2026 14:16:32 +0000 Subject: [PATCH] storkit: create 453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure --- ..._with_fatal_runtime_error_on_restart_after_gate_failure.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md b/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md index afc69e72..baf114de 100644 --- a/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md +++ b/.storkit/work/1_backlog/453_bug_agent_pty_crashes_with_fatal_runtime_error_on_restart_after_gate_failure.md @@ -30,7 +30,9 @@ The root cause is unknown. It is NOT caused by zombie process accumulation (that **Ruled out:** Docker capability restrictions (cap_drop: ALL) — tested by temporarily removing all cap_drop/security_opt; crash still occurs. -Remaining areas to investigate: changes to the agent runtime abstraction in story 343, or environment state left behind by the previous agent session. +**Evidence of stale PTY fd:** After all agents stopped, storkit (PID 7) was still holding an open fd to `/dev/pts/ptmx` (fd 46). This is a leaked PTY master fd from a previous agent session. The reader thread spawned by `std::thread::spawn` in `pty.rs` is never joined, so the cloned reader fd stays open in the storkit process after the agent exits. + +Remaining areas to investigate: the unjoined reader thread leaking PTY fds, and whether the leaked fd from the first session interferes with the second PTY allocation. ## How to Reproduce