Python 3.14 introduced a new stack overflow detection mecanism:InternalDocs/stack_protection.md (#130396).

The KiCad application uses C++ Boostmake_fcontext() coroutines which runs coroutine intheir own stack.

Code example fromfcontext doc:

// context-functionvoidf(intptr);// creates a new stackstd::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 returnedfcontext_tfc(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: Pythondetects a stack overflow because it's not aware that the stack base address and size changed whenmake_fcontext() was called.

pthread functions such aspthread_attr_getguardsize() are incompatible withmake_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