pdb lists source starting from wrong line number if the exception is raised in a try/except block

[dimaqq]

Bug report

Bug description:

MRE

def leaf():
    try:
        assert False
        "padding"
        "padding"
        "padding"
        "padding"
        "padding"
        "padding"
        "padding"
        "padding"
        "padding"
    except IndexError:
        pass


if __name__ == "__main__":
    leaf()

Running this:

> python3.14 -m pdb bar.py
> /code/test-clean/bar.py(1)<module>()
-> def leaf():
(Pdb) c
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.14/lib/python3.14/pdb.py", line 3601, in main
    pdb._run(target)
    ~~~~~~~~^^^^^^^^
  File "/Library/Frameworks/Python.framework/Versions/3.14/lib/python3.14/pdb.py", line 2522, in _run
    self.run(target.code)
    ~~~~~~~~^^^^^^^^^^^^^
  File "/Library/Frameworks/Python.framework/Versions/3.14/lib/python3.14/bdb.py", line 899, in run
    exec(cmd, globals, locals)
    ~~~~^^^^^^^^^^^^^^^^^^^^^^
  File "<string>", line 1, in <module>
  File "/code/test-clean/bar.py", line 18, in <module>
    leaf()
    ~~~~^^
  File "/code/test-clean/bar.py", line 3, in leaf
    assert False
           ^^^^^
AssertionError
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /code/test-clean/bar.py(3)leaf()
-> assert False
(Pdb) list
  8  	        "padding"
  9  	        "padding"
 10  	        "padding"
 11  	        "padding"
 12  	        "padding"
 13  ->	    except IndexError:
 14  	        pass
 15
 16
 17  	if __name__ == "__main__":
 18  	    leaf()
(Pdb)

Note that the traceback reports correct line number (3), but source code listing is focused on line (13) where an unrelated exception would be caught.

The actual location is here:

(Pdb) list 3
  1  	def leaf():
  2  	    try:
  3  >>	        assert False
  4  	        "padding"
  5  	        "padding"
  6  	        "padding"
  7  	        "padding"
  8  	        "padding"
  9  	        "padding"
 10  	        "padding"
 11  	        "padding"

CPython versions tested on:

3.14

Operating systems tested on:

macOS

[dimaqq]

I see similar behaviour on as far back as I can test, so maybe it's like this for a reason?

Py 3.8 and 3.9:

> /code/test-clean/bar.py(3)leaf()
-> assert False
(Pdb) list
  9             "padding"
 10             "padding"
 11             "padding"
 12             "padding"
 13         except IndexError:
 14  ->         pass
 15
 16
 17     if __name__ == "__main__":
 18         leaf()
[EOF]

Py 3.10 ~ 3.15:

> /code/test-clean/bar.py(3)leaf()
-> assert False
(Pdb) list
  8             "padding"
  9             "padding"
 10             "padding"
 11             "padding"
 12             "padding"
 13  ->     except IndexError:
 14             pass
 15
 16
 17     if __name__ == "__main__":
 18         leaf()

[gaogaotiantian]

Okay I believe this is the intended behavior:

The current line in the current frame is indicated by ->. If an exception is being debugged, the line where the exception was originally raised or propagated is indicated by >>, if it differs from the current line.

So it's stated in the documentation that the line where the exception was raised could be different and is indicated with another cursor.

[dimaqq]

Main problem

My biggest gripe is that the "list" command should be centred on the >> cursor, not the -> cursor.

About cursors

I do see the distinction between the two cursors.
However, in this case, IndexError is never raised, and thus, never caught.
Why is the -> cursor on the except IndexError line in the first place?

[gaogaotiantian]

The -> cursor shows the current line - and list command shows source code around the current line.

As for why -> cursor is on the except IndexError line, you can tell that it's not on the pass line - which means the interpreter knows it's not an IndexError. If you dis the function, you'll have something like

   1           RESUME                   0

   2           NOP

   3   L1:     LOAD_COMMON_CONSTANT     0 (AssertionError)
               RAISE_VARARGS            1

  --   L2:     PUSH_EXC_INFO

  13           LOAD_GLOBAL              0 (IndexError)
               CHECK_EXC_MATCH
               POP_JUMP_IF_FALSE        5 (to L6)
       L3:     NOT_TAKEN
       L4:     POP_TOP

  14   L5:     POP_EXCEPT

Because you have an except block, when an exception is raised inside the try block, it jumps to the except line and compare the raised exception with the explicitly handled exceptions. In this case, it failed to match, thus reraised. The RERAISE bytecode corresponds to line 13 - where the exception is compared against IndexError.