Skip to content

Pdb crashes after jump with Fatal Python error: _PyMem_DebugRawFree: bad trailing pad byte #91742

Description

@komoto48g

Crash report

Access violation occurs when using pdb in the following procedure:

  1. step in a function
  2. step next a few lines inside print function
  3. before exiting print function, jump to the beginning of the code
  4. continue
Code Example [test_pdb.py] (click to expand)
__author__ = "pi"
__version__ = "3.14"

def about():
    """About"""
    print(f"Module: {__file__!r}",
          f"Author: {__author__!r}",
          f"Version: {__version__!r}",
          sep='\n')

breakpoint()
about()

Error messages

$ python -Wd -Xdev -Xtracemalloc test_pdb.py

> test_pdb.py(12)<module>()
-> about()
(Pdb) s
--Call--
> test_pdb.py(4)about()
-> def about():
(Pdb) n
> test_pdb.py(6)about()
-> print(f"Module: {__file__!r}",
(Pdb) n
> test_pdb.py(7)about()
-> f"Author: {__author__!r}",
(Pdb) j 4
> test_pdb.py(4)about()
-> def about():
(Pdb) c
Module: 'test_pdb.py'
Author: 'pi'
Version: '3.14'
Debug memory block at address p=0000021D17AD8CF0: API 'o'
    432 bytes originally requested
    The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0000021D17AD8EA0 are not all FORBIDDENBYTE (0xfd):
        at tail+0: 0x90 *** OUCH
        at tail+1: 0x46 *** OUCH
        at tail+2: 0x05 *** OUCH
        at tail+3: 0x17 *** OUCH
        at tail+4: 0x1d *** OUCH
        at tail+5: 0x02 *** OUCH
        at tail+6: 0x00 *** OUCH
        at tail+7: 0x00 *** OUCH
    Data at p: 00 00 00 00 00 00 00 00 ... f0 b4 b5 16 1d 02 00 00

Memory block allocated at (most recent call first):
  File "test_pdb.py", line 12

Fatal Python error: _PyMem_DebugRawFree: bad trailing pad byte
Python runtime state: finalizing (tstate=0000021D169BEA10)

Current thread 0x000033f0 (most recent call first):
<no Python frame>

Your environment

  • CPython versions tested on: 3.10.4
  • Operating system and architecture: Windows10 64bit

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Apr 20, 2022
  2. dignissimus commented on Jun 21, 2022

    @dignissimus
    Contributor

    Commit cf345e9 introduced this issue.
    Running the following minimal example with the below input reproduces the crash.

    def function():
        print(  
          3       
        )
        
    breakpoint()
    function()
    s
    n
    n
    j 1
    c
    
    
  3. dignissimus commented on Jun 21, 2022

    @dignissimus
    Contributor

    PDB attempts to set f_lineno but in doing so it seems to try and de-allocate NULL.

    self.curframe.f_lineno = arg

    static void
    frame_stack_pop(PyFrameObject *f)
    {
    PyObject *v = _PyFrame_StackPop(f->f_frame);
    Py_DECREF(v);
    }

  4. kumaraditya303 commented on Jun 22, 2022

    @kumaraditya303
    Contributor

    Changing Py_DECREF to Py_XDECREF fixes the issue but I'll let @markshannon decide if it is the correct fix.

    cc @markshannon

    GDB backtrace:

    #0  frame_stack_pop (
        f=Frame 0x7ffff7fc0078, for file /workspaces/cpython/main.py, line 7, in about ())
        at Objects/frameobject.c:421
    #1  frame_setlineno (
        f=Frame 0x7ffff7fc0078, for file /workspaces/cpython/main.py, line 7, in about (), 
        p_new_lineno=<optimized out>, _unused_ignored=<optimized out>) at Objects/frameobject.c:641
    #2  0x000055555570c906 in _PyObject_GenericSetAttrWithDict (dict=0x0, value=4, name='f_lineno', 
        obj=Frame 0x7ffff7fc0078, for file /workspaces/cpython/main.py, line 7, in about ())
        at Objects/object.c:1386
  5. markshannon commented on Jun 22, 2022

    @markshannon
    Member

    This looks like an old bug, probably dating back to the introduction of LOAD_METHOD.
    LOAD_METHOD pushes a NULL to stack, which could cause this crash. LOAD_GLOBAL can also push a NULL, making this bug much easier to trigger.

    @kumaraditya303 your fix looks correct.

  6. added a commit that references this issue on Jun 23, 2022
  7. added a commit that references this issue on Jun 23, 2022
  8. added a commit that references this issue on Jun 23, 2022
  9. kumaraditya303 commented on Jun 24, 2022

    @kumaraditya303
    Contributor

    Python 3.11 and 3.12 (main) both are fixed now.


    However Python 3.10 is also affected but it crashes on different assertion.

    python: Python/ceval.c:3040: _PyEval_EvalFrameDefault: Assertion `STACK_LEVEL() <= co->co_stacksize' failed.

    cc @markshannon

  10. removed
    3.11only security fixes
    3.12only security fixes
    on Jun 27, 2022
  11. pablogsal commented on Jun 27, 2022

    @pablogsal
    Member

    Removing the 3.11 and 3.12 tags so these are fixed in 3.11 and 3.12.

  12. pablogsal commented on Aug 2, 2022

    @pablogsal
    Member

    I'm removing the release blocker flag because 3.10 was already crashing with this. This will be treated as a regular bugfix.

  13. sunmy2019 commented on Jun 17, 2023

    @sunmy2019
    Member

    Closed as 3.10 is no longer accepting bug fixes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.10 (EOL)end of lifetype-crashA hard crash of the interpreter, possibly with a core dump

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions