Repository navigation
_Py_DumpStack() is not signal-safe the first time it's called #137185
Description
Bug report
The _Py_DumpStack() should be signal-safe, because we typically call it from signal handlers.
This shows up as an error "signal-unsafe call inside of a signal" if you run ./python -m test test_faulthandler -m test_enable_fd -v with TSan enabled.
From the man page:
backtrace() and backtrace_symbols_fd() don't call malloc()
explicitly, but they are part of libgcc, which gets loaded
dynamically when first used. Dynamic loading usually triggers
a call to malloc(3). If you need certain calls to these two
functions to not allocate memory (in signal handlers, for
example), you need to make sure libgcc is loaded beforehand.
(I think backtrace() is in libc, but it calls __libc_unwind_link_get(), which is in libgcc)
If we are going to call backtrace() from a signal handler, we should ensure that libgcc is loaded when we install the signal handler. We can do this by calling backtrace() early, at signal handler installation time, to force libgcc to be loaded.
Activity
[-]`_Py_DumpTraceback()` is not signal-safe the first time it's called[/-][+]`_Py_DumpStack()` is not signal-safe the first time it's called[/+]pythongh-137185: Fix `_Py_DumpStack()` async signal safety
pythongh-137185: Fix `_Py_DumpStack()` async signal safety
pythongh-137185: Fix `_Py_DumpStack()` async signal safety
pythongh-137185: Fix `_Py_DumpStack()` async signal safety
pythongh-137185: Fix `_Py_DumpStack()` async signal safety
gpshead commentedon Jul 29, 2025
nice find!
gh-137185: Fix `_Py_DumpStack()` async signal safety (gh-137187)
pythongh-137185: Fix `_Py_DumpStack()` async signal safety (pythongh-…
pythongh-137185: Fix `_Py_DumpStack()` async signal safety (pythongh-…
[3.14] gh-137185: Fix `_Py_DumpStack()` async signal safety (gh-137187)…