Crash when using _Py_DumpTracebackThreads

[nascheme]

Crash report

What happened?

# triggering program
# based on test.test_faulthandler.FaultHandlerTests.test_dump_traceback_threads

import faulthandler
from threading import Thread, Event


class Waiter(Thread):

 def __init__(self):
 Thread.__init__(self)
 self.running = Event()
 self.stop = Event()

 def run(self):
 self.running.set()
 self.stop.wait()


def main():
 for i in range(100):
 waiter = Waiter()
 waiter.start()
 waiter.running.wait()
 faulthandler.dump_traceback(all_threads=True)
 waiter.stop.set()
 waiter.join()

if __name__ == '__main__':
 main()

This will case the interpreter to segfault if built with --disable-gil --with-pydebug. I've bisected it to this commit:

b2afe2a: gh-123924

Using gdb:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
_PyFrame_GetCode (f=f@entry=0x7ffff7fb32d8) at ./Include/internal/pycore_frame.h:83
83	 assert(PyCode_Check(executable));
(gdb) p executable 
$7 = 0x0
(gdb) bt
#0 _PyFrame_GetCode (f=f@entry=0x7ffff7fb32d8) at ./Include/internal/pycore_frame.h:83
#1 PyUnstable_InterpreterFrame_GetLine (frame=frame@entry=0x7ffff7fb32d8) at Python/frame.c:149
#2 0x000055555590e9eb in dump_frame (fd=2, frame=0x7ffff7fb32d8) at Python/traceback.c:905
#3 dump_traceback (fd=fd@entry=2, tstate=tstate@entry=0x555555cef140, write_header=write_header@entry=0) at Python/traceback.c:974
#4 0x000055555590ed1c in _Py_DumpTracebackThreads (fd=2, interp=<optimized out>, interp@entry=0x0, current_tstate=0x555555c5dea8 <_PyRuntime+359528>) at Python/traceback.c:1090
#5 0x0000555555924489 in faulthandler_dump_traceback_py (self=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at ./Modules/faulthandler.c:240
#6 0x00005555556feae1 in cfunction_call (func=func@entry=<built-in method dump_traceback of module object at remote 0x20000778900>, args=args@entry=(), kwargs=kwargs@entry={'all_threads': True})
[...]

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.14.0a0 experimental free-threading build (bisect/bad:b2afe2aae48, Jan 1 2025, 17:09:16) [Clang 19.1.6 (++20241217105838+657e03f8625c-1exp120241217105944.74)]

Linked PRs

• gh-128400: Stop-the-world when manually calling faulthandler #128422
• [3.13] gh-128400: Stop-the-world when manually calling faulthandler (GH-128422) #128423
• gh-128400: Only show the current thread in faulthandler if the GIL is disabled #128425
• gh-128400: Only show the current thread in Py_FatalError on the free-threaded build #128758

[ZeroIntensity]

It's probably because accessing fields on another thread state isn't very safe, especially on free-threading. Maybe we should just make a stop-the-world pause for manual invocation of faulthandler?

[colesbury]

Maybe we should just make a stop-the-world pause for manual invocation of faulthandler?

Yes, I think that would make sense.

[colesbury]

@ZeroIntensity - if you're interested in a related follow-up thread safety issue, I think it'd be helpful to make faulthandler only dump the current thread's stack when called from a signal handler. Basically, I think we should ignore all_threads=True in the free threading build because accessing other thread's stacks while they're running is likely to crash. It's not exactly thread-safe in the default build either, but it mostly works whereas in the free threading build it frequently crashes.

[ZeroIntensity]

Sure, I can do that.

[dgrisby]

Even with the GIL, faulthandler is not safe to use in a multi-threaded process: #116008