#20384 Panic handler from `maybe_set_panic_handler` can deadlock Issue created by tgolsson Describe the bug Somewhat related to #16969, I found a case where our

maybe_set_panic_handler

implementation leads to unsoundness. Specifically, if a panic happens somewhere in IO code related to the dynamic/exclusive UI (

Destination

et al) or somewhere in indicatif while holding the state lock. In that case, the panic handler - also invoking

log!

- will have to take both of those locks, and a deadlock occurs. I cannot see any easy fixes while in a dynamic UI situation, as any output at that point that doesn't use indicatif (or prodash??) would likely be immediately overdrawn. At the same time, attempting to output with any of our sanctioned methods would again deadlock. We could work around some issues by caching and using fallback values where we currently take locks - especially

stderr_use_color

, but it would just delay the failure until we try to take the indicatif state lock. Also, in the very specific trigger case I found there was a bug (and subsequent panic/assertion failure) in indicatif itself, which likely means that even if we got past both locks we'd just hit the same panic again -- leading to infinite recursion and exploding. I did some git history spelunking, and the hook has been unchanged for many years. Not sure if all composite parts existed back then though. At the same time, I couldn't find any definite reports of this deadlock actually occuring. Thus I'm mostly reporting this in case someone has a genius idea for handling it, or for someone to find again in the future while debugging deadlocks in the future. pantsbuild/pants