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-139653: If platform API doesn't give the current stack, use generic fallback #139667
• gh-139653: Add PyUnstable_ThreadState_SetStackProtection() #139668
• gh-139653: Remove assertions in _Py_InitializeRecursionLimits() #141551
• [3.14] gh-139653: Add PyUnstable_ThreadState_SetStackProtection() (GH-139668)  #141661
• GH-139653: Only raise an exception (or fatal error) when the stack pointer is about to overflow the stack. #141711
• [3.14] GH-139653: Only raise an exception (or fatal error) when the stack pointer is about to overflow the stack. (GH-141711) #141892
• [3.14] GH-139653: Only raise an exception (or fatal error) when the stack pointer is about to overflow the stack. (GH-141711) #141944