Python 3.14 stack overflow detection is incompatible with C++ Boost make_fcontext() coroutines
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Python 3.14 introduced a new stack overflow detection mecanism: InternalDocs/stack_protection.md (#130396).
The KiCad application uses C++ Boost make_fcontext() coroutines which runs coroutine in their own stack.
Code example from fcontext doc:
// context-function
void f(intptr);
// creates a new stack
std::size_t size = 8192;
void* sp(std::malloc(size));
// context fc uses f() as context function
// fcontext_t is placed on top of context stack
// a pointer to fcontext_t is returned
fcontext_t fc(make_fcontext(sp,size,f));
_Py_InitializeRecursionLimits() is called in the main thread, whereas _Py_CheckRecursiveCall() is called for the first time in a coroutine (make_fcontext()).
Problem: Python detects a stack overflow because it's not aware that the stack base address and size changed when make_fcontext() was called.
pthread functions such as pthread_attr_getguardsize() are incompatible with make_fcontext().
cc @markshannon
Linked PRs
- gh-139667
- gh-139668
- gh-141551
- gh-141661
- gh-141711
- gh-141892
- gh-141944
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with InternalDocs/stack_protection.md, then trace _Py_InitializeRecursionLimits() and the first _Py_CheckRecursiveCall() from a Boost make_fcontext() coroutine. Review the linked PRs to understand the current direction and whether the stack-base and size transition is already addressed; done means coroutine stacks no longer trigger a false stack-overflow detection.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, python
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100