Skip to content

Segfault in test_recursionlimit_fatalerror #72366

Closed
Closed
Segfault in test_recursionlimit_fatalerror#72366
Labels
3.7 (EOL)end of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-crashA hard crash of the interpreter, possibly with a core dump

Description

@berkerpeksag
berkerpeksag
opened on Sep 16, 2016
BPO 28179
Nosy @terryjreedy, @vstinner, @larryhastings, @ned-deily, @berkerpeksag, @serhiy-storchaka, @zhangyangyu, @iritkatriel
Superseder
  • bpo-42500: crash with unbounded recursion in except statement
    		•
    Files
  • full_output.txt
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2021-02-18.05:48:07.997>
created_at = <Date 2016-09-16.09:22:18.605>
labels = ['interpreter-core', '3.7', 'type-crash']
title = 'Segfault in test_recursionlimit_fatalerror'
updated_at = <Date 2021-02-18.05:48:07.996>
user = 'https://github.com/berkerpeksag'

    bugs.python.org fields:

    activity = <Date 2021-02-18.05:48:07.996>
actor = 'berker.peksag'
assignee = 'none'
closed = True
closed_date = <Date 2021-02-18.05:48:07.997>
closer = 'berker.peksag'
components = ['Interpreter Core']
creation = <Date 2016-09-16.09:22:18.605>
creator = 'berker.peksag'
dependencies = []
files = ['44688']
hgrepos = []
issue_num = 28179
keywords = []
message_count = 9.0
messages = ['276686', '276750', '276786', '276787', '276808', '276809', '278436', '387151', '387201']
nosy_count = 8.0
nosy_names = ['terry.reedy', 'vstinner', 'larry', 'ned.deily', 'berker.peksag', 'serhiy.storchaka', 'xiang.zhang', 'iritkatriel']
pr_nums = []
priority = 'high'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '42500'
type = 'crash'
url = 'https://bugs.python.org/issue28179'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7']

    Activity

    1. berkerpeksag commented on Sep 16, 2016

      @berkerpeksag
      berkerpeksag
      on Sep 16, 2016
      MemberAuthor

      This is a follow-up from msg275748 in bpo-27213 (Rework CALL_FUNCTION* opcodes). I believe the test_runpy failure I mentioned there is also the same error, but this one can be reproduced easily.

      test_recursionlimit_fatalerror in SysModuleTest (Lib/test/test_sys.py) segfaults on Ubuntu 12.04 (64-bit) with GCC 4.6.3. I compiled Python with the following commands:

          $ make distclean
    $ ./configure --with-pydebug
    $ make -s -j

      To reproduce it, run (adapted from the test)

          import sys

    def f():
        try:
            f()
        except RecursionError:
            f()

    sys.setrecursionlimit(10)

    f()

      I tried with different values like 50, 10, 1000 and the behavior is same.

      In case it helps, here is the start of the backtrace:

      #2 0x00000000004242fa in Py_FatalError (msg=0x6e0990 "Cannot recover from stack overflow.") at Python/pylifecycle.c:1457
      #3 0x00000000005b6bf8 in _Py_CheckRecursiveCall (where=0x6ac0c8 " while calling a Python object") at Python/ceval.c:651
      #4 0x000000000045d701 in _PyObject_FastCallDict (func=<built-in method flush of _io.TextIOWrapper object at remote 0x7ffff6607580>, args=0x0, nargs=0, kwargs=0x0) at Objects/abstract.c:2292
      #5 0x000000000045e4e9 in callmethod (func=<built-in method flush of _io.TextIOWrapper object at remote 0x7ffff6607580>, format=0x0, va=0x7ffffff36eb0, is_size_t=0) at Objects/abstract.c:2569
      #6 0x000000000045e872 in _PyObject_CallMethodId (o=<_io.TextIOWrapper at remote 0x7ffff6607580>, name=0x94c030, format=0x0) at Objects/abstract.c:2626
      #7 0x0000000000421ceb in flush_std_files () at Python/pylifecycle.c:515
      #8 0x00000000004242f2 in Py_FatalError (msg=0x6e0990 "Cannot recover from stack overflow.") at Python/pylifecycle.c:1436
      #9 0x00000000005b6bf8 in _Py_CheckRecursiveCall (where=0x6e09db "") at Python/ceval.c:651
      #10 0x00000000005b6f3c in _PyEval_EvalFrameDefault (f=Frame 0xabf4a8, for file a.py, line 3, in f (), throwflag=0) at Python/ceval.c:1003
      #11 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf4a8, for file a.py, line 3, in f (), throwflag=0) at Python/ceval.c:718
      Python Exception <class 'gdb.error'> There is no member named dk_entries.:
      #12 0x00000000005d4b85 in _PyFunction_FastCall (co=0x7ffff65731c0, args=0xabf3e8, nargs=0, globals=) at Python/ceval.c:4845
      #13 0x00000000005d4d7a in fast_function (func=<function at remote 0x7ffff6496338>, stack=0xabf3e8, nargs=0, kwnames=0x0) at Python/ceval.c:4880
      #14 0x00000000005d4841 in call_function (pp_stack=0x7ffffff39030, oparg=0, kwnames=0x0) at Python/ceval.c:4784
      #15 0x00000000005cc464 in _PyEval_EvalFrameDefault (f=Frame 0xabf258, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:3250
      #16 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf258, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:718
      Python Exception <class 'gdb.error'> There is no member named dk_entries.:
      #17 0x00000000005d4b85 in _PyFunction_FastCall (co=0x7ffff65731c0, args=0xabf198, nargs=0, globals=) at Python/ceval.c:4845
      #18 0x00000000005d4d7a in fast_function (func=<function at remote 0x7ffff6496338>, stack=0xabf198, nargs=0, kwnames=0x0) at Python/ceval.c:4880
      #19 0x00000000005d4841 in call_function (pp_stack=0x7ffffff3afa0, oparg=0, kwnames=0x0) at Python/ceval.c:4784
      #20 0x00000000005cc464 in _PyEval_EvalFrameDefault (f=Frame 0xabf008, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:3250
      #21 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf008, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:718

    2. berkerpeksag
      added
      3.7 (EOL)end of life
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Sep 16, 2016

    3. terryjreedy commented on Sep 16, 2016

      @terryjreedy
      terryjreedy
      on Sep 16, 2016
      Member

      Running with fresh build from IDLE in a subprocess on Win10, with 15 instead of 10, I quickly get a fatal Python error and the Windows box equivalent to a segfault.

    4. serhiy-storchaka
      added
      release-blocker
      on Sep 16, 2016

    5. zhangyangyu commented on Sep 17, 2016

      @zhangyangyu
      zhangyangyu
      on Sep 17, 2016
      Member

      This snippet also crashes in Py3.5

    6. berkerpeksag commented on Sep 17, 2016

      @berkerpeksag
      berkerpeksag
      on Sep 17, 2016
      MemberAuthor

      What do you mean by crash? I think the purpose of the test is to crash the interpreter:

          def test_recursionlimit_fatalerror(self):
        # A fatal error occurs if a second recursion limit is hit when recovering
        # from a first one.
          ...

              self.assertIn(
            b"Fatal Python error: Cannot recover from stack overflow",
            err)

      test_sys passes for me in Python 3.5, but not in Python 3.6:

      ======================================================================
      FAIL: test_recursionlimit_fatalerror (test.test_sys.SysModuleTest)
      ----------------------------------------------------------------------

      Traceback (most recent call last):
  File "/home/berker/projects/cpython/default/Lib/test/test_sys.py", line 281, in test_recursionlimit_fatalerror
    err)
AssertionError: b'Fatal Python error: Cannot recover from stack overflow' not found in b''

      Running the snippet from msg276686 in Python 3.6:

          $ ./python -V
    Python 3.6.0b1+

    $ ./python a.py  
    Segmentation fault (core dumped)

      In Python 3.5:

          $ ./python -V
    Python 3.5.2+

    $ ./python a.py 
    Fatal Python error: Cannot recover from stack overflow.
      Current thread 0x00007f5965eaf700 (most recent call first):
  File "a.py", line 5 in f
  File "a.py", line 5 in f
  File "a.py", line 5 in f
[...]

    7. terryjreedy commented on Sep 17, 2016

      @terryjreedy
      terryjreedy
      on Sep 17, 2016
      Member

      I also got the same result on 3.5 as 3.6.

    8. terryjreedy commented on Sep 17, 2016

      @terryjreedy
      terryjreedy
      on Sep 17, 2016
      Member

      And the test passes on Windows on both versions.

    9. ned-deily commented on Oct 10, 2016

      @ned-deily
      ned-deily
      on Oct 10, 2016
      Member

      Since this is also reproducible on some 3.5.2 platforms, I don't think it qualifies as a release blocker for 3.6.0. But it still should be addressed.

    10. ned-deily
      removed
      release-blocker
      on Oct 10, 2016

    11. iritkatriel commented on Feb 17, 2021

      @iritkatriel
      iritkatriel
      on Feb 17, 2021
      Member

      I'm not seeing this crash on master. I believe is was fixed under bpo-42500, which add this case as a unit test: see recurse_in_body_and_except in

      4e7a69b#diff-3dbd58a46964dc5908595a1caa552fa3f5e2e46610679634ffc1064fd7cc3c8fR1106

    12. berkerpeksag commented on Feb 18, 2021

      @berkerpeksag
      berkerpeksag
      on Feb 18, 2021
      MemberAuthor

      Yes, this indeed seems to be fixed by bpo-42500 and can be closed now. Nice detective work, thank you!

    13. berkerpeksag
      closed this as completedon Feb 18, 2021
    14. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    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

      3.7 (EOL)end of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-crashA hard crash of the interpreter, possibly with a core dump

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions