gh-128400: Only show the current thread in faulthandler if the GIL is disabled
#128425
Conversation
Modules/faulthandler.c
Outdated
| { | ||
| return 0; | ||
| } | ||
| if (tstate->interp->gc.collecting) |
There was a problem hiding this comment.
The gc.collecting field doesn't necessarily imply that all threads are paused:
gc.collectingis set before the stop-the-world pause- The GC resumes threads while calling finalizers
You could check tstate->interp->stoptheworld.world_stopped and maybe also that tstate matches stoptheworld.requester. (The faulting thread may not be attached to the interpreter when it crashes.)
There was a problem hiding this comment.
I'm not fully convinced that this is worth the extra complexity or the extra chance of crashing during the faulthandler:
- Most crashes probably won't occur during a stop-the-world pause and for those that do, the stack traces of other threads are even less likely to be relevant (because they're paused).
- Even during a stop-the-world pause, looping over the linked list of thread states is not safe without a
HEAD_LOCK(), which you can't do during a signal handler.
There was a problem hiding this comment.
Yeah, I was on the fence about it too. I threw it in there because it seemed simple enough at first, but I think it's better to remove it too.
I think it's best not to stop-the-world. Deadlocks that hide the fatal error message would not be fun. |
|
I'll deal with |
ZeroIntensity
changed the title
faulthandler if other threads are activefaulthandler if the GIL is disabled
Co-authored-by: Sam Gross <colesbury@gmail.com>
Co-authored-by: Sam Gross <colesbury@gmail.com>
|
ASan failure looks unrelated. |
I'd lean towards "no" for now |
…e GIL is disabled (pythonGH-128425)
A few notes here:
Py_FatalErrorstill displays all threads, but that's a seperate bug--is it safe to stop-the-world during a fatal error?📚 Documentation preview 📚: https://cpython-previews--128425.org.readthedocs.build/