Repository navigation
Intermittent CI failures: Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow #694
Copy link
Copy link
Description
We have started to see intermittent failures in CI like this one: https://github.com/JuliaPy/PythonCall.jl/actions/runs/18520695490/job/52779794536
Observed on:
- Julia 1.9 and 1.12
- Mac and Linux
- Python 3.14
Suspiciously started soon after Python 3.14 was released, I suspect we have another ABI issue.
Here is the full error:
Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used -367886 kB) while calling a Python object
Python runtime state: initialized
Thread 0x0000000304bf7000 (most recent call first):
<no Python frame>
Current thread 0x0000000200207200 (most recent call first):
<no Python frame>
[5793] signal (6): Abort trap: 6
in expression starting at /Users/runner/work/PythonCall.jl/PythonCall.jl/test/GIL.jl:14
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
pthread_kill at /usr/lib/system/libsystem_pthread.dylib (unknown line)
abort at /usr/lib/system/libsystem_c.dylib (unknown line)
fatal_error_exit at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
fatal_error at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
_Py_FatalErrorFunc at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
_Py_CheckRecursiveCall at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
method_vectorcall_NOARGS at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
PyObject_VectorcallMethod at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
flush_std_files at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
fatal_error at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
_Py_FatalErrorFunc at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
_Py_CheckRecursiveCall at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
cfunction_vectorcall_FASTCALL_KEYWORDS at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
_PyObject_CallFunctionVa at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
PyObject_CallFunction at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
PyImport_Import at /private/var/folders/q0/wmf37v850txck86cpnvwm_zw0000gn/T/jl_k5lUcu/.CondaPkg/.pixi/envs/default/lib/libpython3.14.dylib (unknown line)
PyImport_Import at /Users/runner/work/PythonCall.jl/PythonCall.jl/src/C/pointers.jl:300 [inlined]
macro expansion at /Users/runner/work/PythonCall.jl/PythonCall.jl/src/Core/Py.jl:118 [inlined]
pyimport at /Users/runner/work/PythonCall.jl/PythonCall.jl/src/Core/builtins.jl:1458
#3 at /Users/runner/work/PythonCall.jl/PythonCall.jl/test/GIL.jl:8 [inlined]
lock at /Users/runner/work/PythonCall.jl/PythonCall.jl/src/GIL/GIL.jl:39
macro expansion at /Users/runner/work/PythonCall.jl/PythonCall.jl/test/GIL.jl:7 [inlined]
#5257#threadsfor_fun#2 at ./threadingconstructs.jl:206
#5257#threadsfor_fun at ./threadingconstructs.jl:173 [inlined]
#1 at ./threadingconstructs.jl:145
unknown function (ip: 0x12092235f)
ijl_apply_generic at /Users/runner/hostedtoolcache/julia/1.9.4/x64/lib/julia/libjulia-internal.1.9.dylib (unknown line)
start_task at /Users/runner/hostedtoolcache/julia/1.9.4/x64/lib/julia/libjulia-internal.1.9.dylib (unknown line)
Allocations: 35353796 (Pool: 35322249; Big: 31547); GC: 53
Package PythonCall errored during testing (received signal: 6)
Reactions are currently unavailable
Activity
ranocha commentedon Oct 23, 2025
I have a similar stack overflow error locally:
I am using macOS Tahoe 26.0.1.
Originally reported in jverzani/SymPyPythonCall.jl#56
cjdoris commentedon Oct 23, 2025
Thank you. Is that the entire error message? It's not much of a backtrace, but that is typical for Mac I think. Can you give the output of
CondaPkg.status()andPythonCall.C.CTXandversioninfo()please?cjdoris commentedon Oct 23, 2025
Oh someone mentioned recently something about finding that doing anything multithreaded in PythonCall would crash if the thing being multithreaded wasn't compiled yet. I can't remember the details but maybe that's it. On Linux, these failures occur in
test/GIL.jlon the first call tothreaded_sleep()which is when it will be compiled. So maybe compiling it but only running on one thread would do the trick, or something like this.ranocha commentedon Oct 24, 2025
Yes, that's the entire stacktrace. Here are the other details:
cjdoris commentedon Oct 24, 2025
Thanks. Can you try doing
CondaPkg.add("python", version="3.13.*")before anything else to see if the error is only with Python 3.14?ranocha commentedon Oct 24, 2025
Great intuition! Indeed, everything seems to be fine with Python 3.13:
cjdoris commentedon Oct 24, 2025
Great thanks. And just to check - with python 3.14 does the error you showed happen every time?
ranocha commentedon Oct 24, 2025
Yes - it happens every time I execute code like in the examples above.
cjdoris commentedon Oct 25, 2025
My guess is we're accidentally relying on some CPython internals that have changed in Python 3.14 and not the Stable ABI.
I think most of extras.jl can now be removed as the corresponding functions are now in the Stable ABI so we can put them in pointers.jl instead. This might be the source of the problem.
cjdoris commentedon Oct 25, 2025
Ah it appears to be to do with a change in how the recursion limit check is performed in Python 3.14. The following post seems highly relevant: https://discuss.python.org/t/fatal-python-error-py-checkrecursivecall-unrecoverable-stack-overflow-used-406047-kb-while-calling-a-python-object/104183/2
As with that post, perhaps Julia tasks have their own stack and are fooling the recursion check. Not sure how to work around this though.
cjdoris commentedon Oct 25, 2025
Perhaps we need some
Py_EnterRecursiveCallandPy_LeaveRecursiveCallsomewhere.Add CondaPkg.toml to pin Python < 3.14 for NonlinearSolveSciPy
Add CondaPkg.toml to pin Python < 3.14 for NonlinearSolveSciPy
cjdoris commentedon Nov 14, 2025
See https://discuss.python.org/t/python-3-14-0-is-incompatible-with-stack-switching-systems-what-do-we-do/104880 for an explanation of what's going on.
cjdoris commentedon Nov 14, 2025
Until the picture becomes clearer, I've restricted CondaPkg.toml to Python <3.14.
cjdoris commentedon Nov 28, 2025
Good news! I think this will most likely be fixed by python/cpython#141944 which should be in the next patch release of Python 3.14.
dpinol commentedon Dec 3, 2025
Unfortunately python 3.14.1 comes with this issue :-( python/cpython#142214
dpinol commentedon Dec 11, 2025
Does this still occur with python 3.14.2?
cjdoris commentedon Dec 15, 2025
Let's see! #733
cjdoris commentedon Dec 15, 2025
Woohoo! We're back in business.