[adeerkhan]

Part of #1624

The problem

err_trap, the host SIGSEGV/SIGBUS handler, ended in err_fail, so it called fflush(stdout) and fprintf(stderr, ...) from inside a signal handler. Two things could go wrong:

• A fault inside stdio could fault again in the flush. SIGSEGV is blocked inside the handler, so that second fault either killed the process with no numbered line (Linux) or hung it (macOS).
• A fault and a fail-stop on two threads, or two faults at once, raced to print. The wrong cause could win, or the line could be printed twice.

The fix

• err_claim picks one thread to end the process. It records the first caller's pthread_self() in an atomic with a compare-and-swap, and only that thread flushes stdout. Any other thread waits a second (nanosleep, resumed after a signal) for that thread's _exit. It may be holding the very lock the claimer is flushing on, so after the second it prints its own line and exits rather than hang. A second fault on the claiming thread's own exit path skips the flush and goes straight to the line. err_claim needs no setup and allocates nothing, on any thread. Both err_fail and err_trap call it.
• The trap never waits. It flushes stdout only if ftrylockfile succeeds. Then it writes the constant bend: <ERRS[7]>\n (the text the JS trap already uses) with one write(2), and calls _exit(1). Stdout goes before the line, so a log that combines stdout and stderr keeps its order.
• A fault inside that flush still prints the line. The trap is installed with SA_NODEFER, so a fault in the flush re-enters it. err_claim returns 0 on re-entry, so the flush is skipped and the line goes out. The altstack is 4 * SIGSTKSZ so the nested frame fits.
• err_fail still prints with fprintf, so a message of any length goes out whole. It is now OUTLINE (cold, never inlined) and err_claim is FAR. When err_fail was inlined at its call sites, its larger body made editdist and merkle SEQ-CPU 1.24x and 1.32x slower on the minis, in three runs each.
• io_errs and IO.print send the text and its newline in one write. They use the byte io_cbuf leaves for the NUL, so a fail-stop cannot land between the text and its newline.

tests/io/stack_fault_trap.bend prints BEFORE before the deep call and expects #|BEFORE above the error line. That pins the trap's flush against removal (stdout is buffered when it goes to a pipe).

Verification

Gates on b66cf64 over main b0d1ca6:

• repo 54/54 (comp.ts 65,489 / 66,000)
• test 1692/1692
• ping 63/63
• perf 124/124
• safe: 0 false rejects

A C harness ran the emitted err_claim, err_fail and err_trap verbatim, with stdout and stderr captured as one stream:

case	output	exit
plain fault	BEFORE, line	1
7 threads fault at once	BEFORE, exactly one line, 100/100 runs	1
a fail-stop while another thread faults	BEFORE, bend: <the fail-stop's message> only	1
a fault inside the trap's flush	line	1
a fault inside err_fail's flush	line	1
a fault on a thread holding stdout while another is in err_fail	line after 1s (hung before this change)	1
the same, with a handled signal sent to the waiting thread every 50ms	one line after the full second	1
the faulting thread holds the stdout lock	BEFORE, line	1
another thread holds stdout	line (the flush is skipped, never waited on)	1
main returns while another thread is faulting	line (was exit 0 with no line under a wait-based version)	1
a thread that never set up an altstack faults	line, and a malloc hook saw no allocation in the handler	1

The harness ran on macOS (arm64) only. The glibc path has not been run.

Trade-offs

• The trap drops the flush if another thread holds stdout at that instant. Waiting inside a signal handler lets the program keep running past the fault.
• A second failing thread waits only a second for the first one's flush. If stdout is a pipe that is slow to drain, it can exit before the flush finishes, cutting stdout short; the line is still printed. Waiting longer brings back the hang this avoids.
• A flush that blocks forever on a pipe nobody reads hangs before the line, as main does. Writing the line first would put it ahead of stdout in a combined log.

Out of scope

• Re-raising the signal (the issue's second option). stack_fault_trap requires the numbered line and exit 1, never death by signal.
• A fatal hook for embedders (the issue's first option), and the atexit/termios restore. Both are still open in err_fail's _exit and stdio leave an embedder no fatal path (terminal state, signals) #1624.
• io_help threads have no altstack, so a stack overflow there still dies silently. That is true on main too.

🤖 Generated with Claude Code

[Lorenzobattistela]

Thanks for this. The async-signal-safety point is real, but the change as written regresses two things the old path did right, so I'm requesting changes. All gates pass with this merged onto main bedc964 (repo 54/54, test 1656/1656, perf 124/124, ping 62/62, safe 0 false rejects). Neither regression is covered by a test.

1. A stack fault now loses output the program already printed. Stdout is fully buffered when it goes to a pipe or file, and err_trap no longer flushes it. Take tests/io/stack_fault_trap.bend, add a : Unit <- IO.print("BEFORE") before the deep call, build it with bend x.bend -o x, then run ./x | cat:

   • main: BEFORE on stdout, then bend: memory fault (machine stack overflow?)
   • this PR: only the error line; BEFORE is gone

   This happens with --threads 1 and --threads 4. Running through bend x.bend hides it, so the byte-identical checks in the description didn't catch it.

2. When several threads fail at once, their error lines interleave. err_write sends the line as three separate write(2) calls. Before, fprintf held the stderr lock and sent the whole line at once. A parallel tree of 2^14 leaves that each overflow a Nat printed garbled stderr in 80 of 100 runs here (e.g. bend: bend: bend: a Nat past the largest immediate 2^48-1a Nat past ...) and in 0 of 100 on main. Since tests compare stderr against their #| lines, any test with parallel failures would become flaky.

Suggested shape:

• Build "bend: <msg>\n" in a stack buffer and send it with one write(2). That's still async-signal-safe, it can't interleave (the line is under PIPE_BUF), and it drops the ssize_t n ...; (void)n; workaround. Loop on short writes and EINTR so the numbered line is never cut off.
• Keep the flush in err_trap when it's free: if (ftrylockfile(stdout) == 0) { fflush(stdout); funlockfile(stdout); }. The stdio locks are recursive on macOS and glibc, so a fault on the thread that holds the stdout lock doesn't deadlock. If another thread holds it, the trap skips the flush instead of waiting.
• Guard msg against NULL. fprintf printed "(null)", but strlen(NULL) faults. From reading the code: gpu_fail passes [[err localizedDescription] UTF8String], which is NULL when err is nil.
• Drop the "no buffered output worth risking a hang for" comment; point 1 shows there often is.
• Pin both cases in tests: an IO.print before the fault in stack_fault_trap.bend with #|BEFORE above the error line, and ideally one parallel fail-stop test that expects a single clean line.

Also, this covers only the stdio part of #1624. The atexit/termios restore and the re-raise of the real signal are still open, so "Part of #1624" fits better than "Resolves".

[adeerkhan]

@Lorenzobattistela thanks — both regressions were real, and the review's shape is what the fix is now.

1. The trap lost output it had already printed. err_trap flushes stdout again, under a try-lock:

if (ftrylockfile(stdout) == 0) { fflush(stdout); funlockfile(stdout); }

ftrylockfile never waits and the stdio locks are recursive, so a fault on the thread that holds the stdout lock flushes fine, and another thread's lock is skipped rather than waited for. err_fail keeps its blocking fflush (it is not a signal handler, so it may wait). The two lock calls are declared in the runtime because they are POSIX and -std=c11 does not ask for them; both are in libc, on glibc and on macOS.

Pinned in tests/io/stack_fault_trap.bend: an IO.print("BEFORE") before the deep call, with #|BEFORE above the error line. All three lanes (interpreter, JS, C) print BEFORE then the error, exit 1. On the previous path of this PR the C lane loses BEFORE — the same binary with the flush removed shows exactly that, which is how I checked the test bites.

2. Threads that fail at once interleaved. The line is one write(2) now: "bend: <msg>\n" is built in a stack buffer and sent whole, so it is under PIPE_BUF and cannot interleave; a short write is resumed and EINTR retried, so the line is never cut. Measured on the mechanism itself — 64 threads writing the line at once, 20 runs each, the three-write form against the new one: 14/20 garbled before, 0/20 after.

msg against NULL. err_write prints (null), as fprintf did; strlen(NULL) faults and gpu_fail passes [[err localizedDescription] UTF8String], which is NULL when err is nil.

The comment. Gone — the flush is there, so "no buffered output worth risking a hang for" was wrong.

Tests. tests/io/parallel_fail_stop.bend is new: a task fails on a pool thread while main is parked on the join, and the expected output is one clean line and exit 1. A test with several failing threads cannot pin the count (the first fail-stop kills the process, so how many lines land is not deterministic), which is why this one fails exactly one task and pins the shape of the line.

"Part of #1624". The description says that now: the atexit/termios restore and the re-raise of the real signal are still open.

One thing to flag: bend2/comp.ts lands at 65,880 ttok against its permanent 66,000 cap (main is 65,507), so this PR costs 373 tokens and the file is 120 short. The next change there needs a simplification first, or the cap owner's call.