Repository navigation
The REPL hangs under low memory on main #140080
Description
Bug report
Bug description:
Its kind of the same issue like #134163
so cc @ZeroIntensity @picnixz
but the root cause is very different
import _testcapi
_testcapi.set_nomemory(100) # or 0 or 1000it will print the error and hang forever
[hyi@rocky cpython]$ ./python
Python 3.15.0a0 (heads/main:8e0bf4fe5d7, Oct 14 2025, 14:01:02) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _testcapi
>>> _testcapi.set_nomemory(0)
object address : 0xffff9c12dea0
object refcount : 3
object type : 0x927c48
object type name: MemoryError
object repr :
lost sys.stderr
# hang herethe root cause is easy but the fix maybe hard and need to discuss so only issue
and digging here no patch
some dig:
- it only happens in main 3.15 and recent commits
- it happends on all system
- both old and default REPL hava it
- its hard to reproduce without repl
the root cause can check bt
➜ ~ lldb -p 23325
(lldb) process attach --pid 23325
warning: python.exe was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 23325 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x0000000100bac6c4 python.exe`BaseException_clear(op=0x00000001011c1e40) at exceptions.c:135:5 [opt]
132 BaseException_clear(PyObject *op)
133 {
134 PyBaseExceptionObject *self = PyBaseExceptionObject_CAST(op);
-> 135 Py_CLEAR(self->dict);
136 Py_CLEAR(self->args);
137 Py_CLEAR(self->notes);
138 Py_CLEAR(self->traceback);
Target 0: (python.exe) stopped.
Executable binary set to "/Users/hyi/prs/cpython/python.exe".
Architecture set to: arm64-apple-macosx-.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x0000000100bac6c4 python.exe`BaseException_clear(op=0x00000001011c1e40) at exceptions.c:135:5 [opt]
frame #1: 0x0000000100bac58c python.exe`MemoryError_dealloc(op=0x00000001011c1e40) at exceptions.c:4099:11 [opt]
frame #2: 0x0000000100bf8fac python.exe`_Py_Dealloc(op=0x00000001011c1e40) at object.c:3200:5 [opt]
frame #3: 0x0000000100d0c9ac python.exe`format_unraisable_v [inlined] Py_DECREF(op=0x00000001011c1e40) at refcount.h:418:9 [opt]
frame #4: 0x0000000100d0c9a4 python.exe`format_unraisable_v [inlined] Py_XDECREF(op=0x00000001011c1e40) at refcount.h:511:9 [opt]
frame #5: 0x0000000100d0c9a4 python.exe`format_unraisable_v(format=<unavailable>, va="8X\xa2\U00000001\U00000001", obj=0x0000000000000000) at errors.c:1746:5 [opt]
frame #6: 0x0000000100d0c428 python.exe`PyErr_FormatUnraisable(format=<unavailable>) at errors.c:1769:5 [opt]
frame #7: 0x0000000100d8017c python.exe`atexit_callfuncs(state=<unavailable>) at atexitmodule.c:113:9 [opt] [artificial]
frame #8: 0x0000000100d80070 python.exe`_PyAtExit_Call(interp=<unavailable>) at atexitmodule.c:151:5 [opt] [artificial]
frame #9: 0x0000000100d471b0 python.exe`make_pre_finalization_calls(tstate=0x0000000100ff8bc0, subinterpreters=1) at pylifecycle.c:2108:9 [opt]
frame #10: 0x0000000100d468dc python.exe`_Py_Finalize(runtime=<unavailable>) at pylifecycle.c:2167:5 [opt]
frame #11: 0x0000000100d46828 python.exe`Py_FinalizeEx at pylifecycle.c:2378:12 [opt] [artificial]
frame #12: 0x0000000100d76854 python.exe`Py_RunMain at main.c:774:9 [opt]
frame #13: 0x0000000100d76fec python.exe`pymain_main(args=0x000000016f2b6140) at main.c:802:12 [opt]
frame #14: 0x0000000100d7708c python.exe`Py_BytesMain(argc=<unavailable>, argv=<unavailable>) at main.c:826:12 [opt]
frame #15: 0x000000019a2e5d54 dyld`start + 7184
(lldb)
- with the perf can check the fucntion
[hyi@rocky ~]$ perf annotate -l --stdio --symbol PyErr_FormatUnraisable
Sorted summary for file /home/hyi/cpython/python
----------------------------------------------
55.56 errors.c:1765
29.63 errors.c:1771
14.81 errors.c:1768
Percent | Source code & Disassembly of python for task-clock:upppH (27 samples, percent: local period)
------------------------------------------------------------------------------------------------------------
:
:
:
: 3 Disassembly of section .text:
:
: 5 0000000000614ac0 <PyErr_FormatUnraisable>:
: 6 _PyErr_Clear(tstate); /* Just in case */
: 7 }
:
: 9 void
: 10 PyErr_FormatUnraisable(const char *format, ...)
: 11 {
0.00 : 614ac0: stp x29, x30, [sp, #-272]!
: 13 va_list va;
:
: 15 va_start(va, format);
0.00 : 614ac4: mov w9, #0xffffffc8 // #-56
0.00 : 614ac8: mov w8, #0xffffff80 // #-128
: 18 {
0.00 : 614acc: mov x29, sp
: 20 va_start(va, format);
0.00 : 614ad0: add x10, sp, #0xd0
0.00 : 614ad4: add x11, sp, #0x110
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Activity
[-]The REPL hangs under no low memory on main[/-][+]The REPL hangs under low memory on main[/+]picnixz commentedon Oct 14, 2025
I don't think it's an issue actually. If the system is constrained to low memory, it's maybe really hard to know when to exit the interpreter (as you see it's probably when shutting it down, and we definitely need some memory I guess here). I would suggest closing this as
not planned.yihong0618 commentedon Oct 14, 2025
copy but it turns out #134163 is a real one and can reproduce without repl
the question is maybe it under low memory and hangs or only in repl if only in repl close is better
ZeroIntensity commentedon Oct 14, 2025
In hindsight, we should have put the test case from #138491 on main and 3.14. A good start would be to bisect which commit is bad.
yihong0618 commentedon Oct 14, 2025
the tests not a reproducer
and will help to bisect later
yihong0618 commentedon Oct 14, 2025
@ZeroIntensity this commit bring the problem 2191497
ZeroIntensity commentedon Oct 14, 2025
Oh, ha, that's my PR. I'll look into it later, unless you want to try it yourself.
yihong0618 commentedon Oct 14, 2025
I make a patch fix it its very interesting, but I am not sure it needs a test(which is hard)
yihong0618 commentedon Oct 14, 2025
in
atexit_callfuncsmake_pre_finalization_calls->interp_has_atexit_callbacks()return true forevergh-140080: Clear `atexit` callbacks when memory allocation fails duri…
ZeroIntensity commentedon Oct 15, 2025
Thanks @yihong0618!
[3.14] gh-140080: Add test for executing `atexit` callbacks under no …
pythongh-140080: Clear `atexit` callbacks when memory allocation fail…