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

[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

[dignissimus]

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

[dignissimus]

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

cpython/Lib/pdb.py

Line 1172 in 4abab6b

self.curframe.f_lineno = arg

cpython/Objects/frameobject.c

Lines 417 to 422 in 296e4ef

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

[kumaraditya303]

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

[markshannon]

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.

[kumaraditya303]

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