1 files changed, 16 insertions, 8 deletions
diff --git a/src/CHANGELOG.md b/src/CHANGELOG.md
index 4cef906d..bb7e9ad5 100644
--- a/src/CHANGELOG.md
+++ b/src/CHANGELOG.md
@@ -15,14 +15,22 @@
   fact. `src/crash.zig` runs inside the panic handler, so it takes no lock of
   this program's, allocates nothing of its own, and every failure is swallowed:
   a crash file that could not be written must not become the crash, and stderr
-  still gets its own copy either way. The file gets RETURN ADDRESSES rather
-  than the symbolised trace, and that is measured rather than chosen —
-  `writeCurrentStackTrace` called from a panic handler *before* `defaultPanic`
-  wedges the process at 0% CPU: symbolising reads DWARF, that read can panic,
-  and the staging which turns a nested panic into "aborting due to recursive
-  panic" is `defaultPanic`'s own and private. Walking frames is safe, so the
-  addresses go in the file and `addr2line -e` against the build named on the
-  line above them finishes the job. The AppKit shell got a panic handler of its
+  still gets its own copy either way. The file carries NO STACK TRACE, and that
+  is measured rather than chosen: `writeCurrentStackTrace` called from a panic
+  handler *before* `defaultPanic` wedges the process at 0% CPU, and
+  `captureCurrentStackTrace` — which looks like the safe half of it — takes
+  `SelfInfo`'s rwlock exclusively on its first call, so a panic inside the walk
+  leaves that lock held and `defaultPanic` waits on it for the life of the
+  process. A crash that becomes a hang is worse than the crash. What makes
+  `defaultPanic` itself survive that is its private `panic_stage`, reachable
+  from nowhere outside `std.debug`, so the frames stay on stderr where they
+  already work. ONE record per process, because the nested panic std's trace
+  printer raises comes back through the handler: the first version of this
+  wrote the real message and then "reached unreachable code" underneath it,
+  which is the panic handler's own second `vaxis.recover()` double-closing the
+  tty — `recover()` never cleared the global saying there was one. That call is
+  guarded now too, in both the panic and the segfault handler, which is a fix
+  older than this file. The AppKit shell got a panic handler of its
   own in the process: the macOS build roots at `macos.zig`, so the one in
   `main.zig` had never run there — in the shell with the least useful stderr of
   the four.