Repository navigation
Implement stack overflow protection for linux based on actual stack depth #130396
Description
Activity
This broke two buildbots (both can be seen in the pre-merge run):
- AMD64 Windows Server 2022 NoGIL (tier 1):
test_trashcan_python_class1loops with endless repetition ofException ignored in audit hook:RecursionError: Stack overflow (used 11729 kB) - AMD64 Fedora Stable Clang 3.x (tier 2): several
test_gdbfailures.
Do you have any leads on these issues?
- AMD64 Windows Server 2022 NoGIL (tier 1):
I'm seeing SIGBUS in a compilation modes that use a lot of stack:
export CC=clang-19 ./configure -C --with-pydebug --with-thread-sanitizer --disable-gil make -j export TSAN_OPTIONS="suppressions=$(pwd)/Tools/tsan/suppressions_free_threading.txt handle_segv=0" ./python -m test test_dictviews -m test_deeply_nested_reprEDIT: The suppressions seems to be important for reproducing the crash.
12 remaining items
- added a commit that references this issue
on Jul 1, 2025 - added 4 commits that reference this issue
on Nov 25, 2025
Linux doesn't offer an API for determining the current stack bounds, at least not that I am aware of.
This means we will need to probe the stack using a SIGSEGV handler and longjmp/setjump.
It is somewhat ugly but should work.
Actually, it looks like
pthread_get_stackaddr_npmight work, and avoid all the complexity of the signal handler. In theory, it should work for MacOS as well.Linked PRs
pthread_get_stackaddr_npon Emscripten #131088