February 10, 2026
Who locked it? Spill the stack!
Show HN: Deadlog – almost drop-in mutex for debugging Go deadlocks
Deadlog hunts stuck code; first reply: “cool, but use synctest”
TLDR: A new Go tool, Deadlog, logs and analyzes lock activity to spotlight deadlocks and “who’s holding up whom.” Early reaction praises the idea but quickly points to Go’s official synctest as the safer, standard path—kicking off the familiar battle between shiny new helpers and built‑in tools for debugging concurrency.
Hacker News just met Deadlog, a “deadlock detective” for Go that promises near drop‑in setup and blow‑by‑blow logs of who grabbed a lock and who never gave it back. It even ships a command‑line analyzer that turns noisy JSON into a clean “who’s stuck, who’s holding” report. Think of it as a security camera for code that gets jammed.
But the crowd immediately gave it the classic HN side‑eye. The very first vibe? A polite “nice work—also, have you seen synctest, the official Go team’s approach for testing time and concurrency?” That single nudge lit the fuse on the eternal debate: shiny new toolkit vs “use the built‑in one.” On one side, folks love Deadlog’s names, stack traces, and instant visibility that makes stuck code feel obvious. On the other, the “keep it standard” camp says official tools and tests should catch most of this without sprinkling logging everywhere.
Cue jokes about the sample lock names (“apply‑damage,” anyone?) making bug hunts feel like boss battles, plus nervous laughter about accidentally shipping debug locks into production. Fans say Deadlog looks like a painless way to expose who forgot to unlock; skeptics counter that more logs can mean more noise. Verdict so far: admiration for a slick tool, with a very HN‑core reminder that the official path exists—and is pretty good too.
Key Points
- •Deadlog is a Go library that wraps sync.Mutex and sync.RWMutex to log lock events for deadlock debugging.
- •It logs START, ACQUIRED, and RELEASED events with a correlation ID to link each lock operation.
- •Features include WithLockName for labeling callsites and WithTrace for stack traces to pinpoint lock locations.
- •A CLI (deadlog analyze) and an analysis library can process logs to report stuck (waiting) and held (unreleased) locks.
- •Logging is configurable: defaults to JSON to stdout but supports custom loggers and writing to specific files; event fields are defined.