Diagnostics: identify the double close behind the async Closer EBADF assertion on the asan lane

Draft
RO
3mo ago
+391-4

Diagnostics only, do not merge

The x64-asan test lane intermittently aborts a bun test --test-worker --isolate process with:

panic: assertion failed: err.is_none()
  src/sys/fd.rs:73      FdExt::close            (debug_assert: "use after close!")
  src/io/lib.rs:2246    closer::Closer::run     (async close on the work pool)
  src/threading/work_pool.rs:66

i.e. by the time the async Closer ran, the fd it was handed had already been closed by something else. The crash report does not say which fd or which object scheduled the close, and it has not reproduced locally with a debug build (the same 52-file batch passes under --isolate and --parallel=N). It reproduces on the asan lane in most builds (seen in builds 95992, 95993, 95999, 96000 x2, 96094 x2, usually attributed to the file that just finished running, e.g. test/cli/test/concurrent-test-glob.test.ts, test/js/node/events/event-emitter.test.ts, test/js/node/readline/stdin-pause-pty.test.ts).

This PR adds debug_assertions-only instrumentation (Linux) so the next occurrence names both sides of the double close:

  • bun_sys::close_ledger: every successful close issued through bun_sys records a backtrace keyed by fd number; an EBADF close prints the attempt's backtrace plus the recorded first closer.
  • Closer captures a backtrace when it is scheduled and prints it before panicking if its close comes back EBADF.

The instrumentation will be removed; the real fix goes in a separate PR once the CI output identifies the owner.