gh-128400: Stop-the-world when manually calling faulthandler

[ZeroIntensity]

• Issue: Crash when using _Py_DumpTracebackThreads #128400

[miss-islington-app]

Thanks @ZeroIntensity for the PR, and @colesbury for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[colesbury]

Thanks!

[bedevere-app]

GH-128423 is a backport of this pull request to the 3.13 branch.

[nascheme]

I'm not sure including the test is a good idea. It looks a bit expensive to me. That code was intended to reliability trigger a crash when using git bisect. I would suspect you could reduce the loop count from 100 to 20 and still reliability trigger it. Maybe even 10 would be enough. OTOH, I don't think the SEGV happened when the dump output was sent to a file, only to the terminal. So with a unit test, when stdout is captured by default, I think that test code will not actually trigger the crash. The existing FaultHandlerTests.test_dump_traceback_threads was triggering the bug, just not very consistently. Maybe that would be good enough? Or, maybe add a couple loops there?

[nascheme]

I tested by backing out the change to faulthandler.c. That test case does trigger a crash but not on every run. So, reducing the loop iterations is probably not a good idea. So, I think we can just leave that test as is.

Thanks for fixing this bug!

[ZeroIntensity]

Ah wait, I did forget @support.requires_resource("cpu")--will the test break due to RuntimeError: can't start new thread on some buildbots?

[colesbury]

I think @threading_helper.requires_working_threading() should be sufficient. The test takes ~110 ms on my machine so I don't think it needs a @support.requires_resource("cpu").