Activity

1. StanFromIreland

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

   topic-parser

   on May 18, 2026
2. StanFromIreland

   changed the title [-]`MemoryError` during parse can escalate to `SystemError` and abort on small `input`[/-] [+]`MemoryError` during parse can escalate to `SystemError` and abort on small input[/+] on May 18, 2026
3. swap357 commented on May 18, 2026

   

   swap357

   on May 18, 2026

   Last edited by swap357

   More actions

   I'm starting to look into this. I can confirm this reproduces on main,

   cpython main  ❯ ./python.exe
   Python 3.15.0a8+ (heads/main:299cf3c497, May 18 2026, 11:18:24) [Clang 17.0.0 (clang-1700.6.3.2)] on darwin
   ...
   >>> compile(string, "<input>", "single")
   Fatal Python error: _Py_CheckFunctionResult: a function returned a result with an exception set
   Python runtime state: initialized
   MemoryError: Parser stack overflowed - Python source too complex to parse
   
   The above exception was the direct cause of the following exception:
   
   SystemError: <class 'SyntaxWarning'> returned a result with an exception set
   ...
   

   I couldn't reproduce this with Python 3.14.4 which gives expected SyntaxError.
4. meghprkh commented on May 18, 2026

   

   meghprkh

   on May 18, 2026

   More actions

   It seems that there is a recursion limit of 6000 which this code-string seems to be exceeding. The recursion happens with function calls / expressions (~) and maybe other parens ([). This string is only 900 characters so there is the case that there is some pessimization of stack recursion in one of the operators being parsed.
5. swap357 commented on May 18, 2026

   

   swap357

   on May 18, 2026

   More actions

   I ran git bisect with the reproducer above. The first bad commit appears to be ccbe41e as the first bad commit.
   (where exit code 1 SyntaxError is treated good, and exit code 134 with SystemError /Abort is bad)
6. encukou commented on May 19, 2026

   

   encukou

   on May 19, 2026

   Member

   More actions

   It seems that we're missing some error handling around here:

   diff --git a/Parser/parser.c b/Parser/parser.c
   index c55c081dfc3..e50bad56da7 100644
   --- a/Parser/parser.c
   +++ b/Parser/parser.c
   @@ -33420,6 +33420,10 @@ _loop0_79_rule(Parser *p)
            p->mark = _mark;
            D(fprintf(stderr, "%*c%s _loop0_79[%d-%d]: %s failed!\n", p->level, ' ',
                      p->error_indicator ? "ERROR!" : "-", _mark, p->mark, "fstring_middle"));
   +        if (p->error_indicator) {
   +            p->level--;
   +            return NULL;
   +        }
        }
        asdl_seq *_seq = (asdl_seq*)_Py_asdl_generic_seq_new(_n, p->arena);
        if (!_seq) {

   The challenge now is to figure out where this is generated from :)
7. sandugood commented on May 19, 2026

   

   sandugood

   on May 19, 2026

   More actions

   The issue was in the Tools/peg_generator/pegen/c_generator.py

   So, basically, that particular part (addressed in the PR) was messing with the generated parser.c, which in result escalated to a SystemError with a crash.
8. sandugood

   added 2 commits that reference this issue on May 23, 2026

   Merge remote-tracking branch 'upstream/main' into pythongh-150001

   fe16f06

   Merge remote-tracking branch 'upstream/main' into pythongh-150001

   5520aa5
9. sandugood

   added 2 commits that reference this issue on Jun 27, 2026

   Merge remote-tracking branch 'upstream/main' into pythongh-150001

   c192c04

   Merge remote-tracking branch 'upstream/main' into pythongh-150001

   3dd8228