Skip to content

The REPL hangs under low memory on main #140080

Description

@yihong0618

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 1000

it 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 here

the 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

Linked PRs

Activity

  1. changed the title [-]The REPL hangs under no low memory on main[/-] [+]The REPL hangs under low memory on main[/+] on Oct 14, 2025
  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    topic-replRelated to the interactive shell
    on Oct 14, 2025
  3. picnixz commented on Oct 14, 2025

    @picnixz
    Member

    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.

  4. added
    pendingThe issue will be closed if no feedback is provided
    on Oct 14, 2025
  5. yihong0618 commented on Oct 14, 2025

    @yihong0618
    ContributorAuthor

    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. I would suggest closing this as not planned (also, the _testcapi.set_nomemory(0) is not meant for real-code usage, just to mimic low memory units).

    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

  6. removed
    pendingThe issue will be closed if no feedback is provided
    on Oct 14, 2025
  7. ZeroIntensity commented on Oct 14, 2025

    @ZeroIntensity
    Member

    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.

  8. yihong0618 commented on Oct 14, 2025

    @yihong0618
    ContributorAuthor

    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.

    the tests not a reproducer
    and will help to bisect later

  9. yihong0618 commented on Oct 14, 2025

    @yihong0618
    ContributorAuthor

    @ZeroIntensity this commit bring the problem 2191497

  10. ZeroIntensity commented on Oct 14, 2025

    @ZeroIntensity
    Member

    Oh, ha, that's my PR. I'll look into it later, unless you want to try it yourself.

  11. yihong0618 commented on Oct 14, 2025

    @yihong0618
    ContributorAuthor

    Oh, ha, that's my PR. I'll look into it later, unless you want to try it yourself.

    I make a patch fix it its very interesting, but I am not sure it needs a test(which is hard)

  12. yihong0618 commented on Oct 14, 2025

    @yihong0618
    ContributorAuthor

    in atexit_callfuncs

    • PyList_GetSlice(...).
    • If this operation fails due to low memory
    • PyErr_FormatUnraisable() is called, and the function returns directly.
    • state->callbacks list not empty
    • In make_pre_finalization_calls -> interp_has_atexit_callbacks() return true forever
    • then loop
  13. added a commit that references this issue on Oct 15, 2025
  14. ZeroIntensity commented on Oct 15, 2025

    @ZeroIntensity
    Member

    Thanks @yihong0618!

  15. added a commit that references this issue on Oct 15, 2025
  16. added a commit that references this issue on Dec 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytopic-replRelated to the interactive shelltype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions