Python 3.13.0b1: suboptimal `pdb._post_mortem` behavior if `.pdbrc` exists about cpython

[gaogaotiantian]

This is more complicated than it appears to be:

1. Where should the stack entry be printed? Before or after the .pdbrc file is processed? I think after is the right way to go but we can't achieve this easily with the current structure.
2. Whether the stack entry should be printed is supposed to be determined by the content of .pdbrc - whether that gives the user chance to input commands, which can not be determined at the entry point of interaction.

This is a real issue and I need to think about how to address it without changes to cmd.Cmd.

[d-maurer]

Tian Gao wrote at 2024-5-31 11:36 -0700:

This is more complicated than it appears to be: 1. Where should the stack entry be printed? Before or after the `.pdbrc` file is processed? I think after is the right way to go but we can't achieve this easily with the current structure.

In my (likely typical) case, the `pdbrc` file contains only alias definitions. In this case, it does not matter whether the print happens before or after the `pdbrc` processing. While the `pdbrc` file may contain non alias commands, I do not think that they are relevant for post mortem debugging. If it contains a command which implicitly prints a stack entry (e.g. `up`), I likely would not mind to see two stack entry prints -- one before the `pdbrc` processing and one as part of the command.

2. Whether the stack entry should be printed is supposed to be determined by the content of `.pdbrc` - whether that gives the user chance to input commands, which can not be determined at the entry point of `interaction`.

Can you give a use case? One where a potentially additional stack entry print before the `pdbrc` processing would be a serious problem?

This is a real issue and I need to think about how to address it without changes to `cmd.Cmd`.

Sure!

…

-- Dieter

[gaogaotiantian]

I realized these days that people are using .pdbrc differently. For example in #119579, the user uses .pdbrc as a debugging script so that they don't have to re-type the commands over and over again.

As you can tell, they use sophisticated comamnds like break, commands etc., maybe even ll or p to display some data. This is a completely valid usage (arguably a useful one), and the outcome is - it will print stuff on the screen! And that would make "before" or "after" a big difference.

The same thing could happen with post-mortem debugging as well - the user could potentially print something to help debugging, and if you print the stack entry before .pdbrc executes, it would be too far away.

And this is not specific to post-mortem debugging, actually this is an issue for all cases involving .pdbrc. That's why I wanted to fix it for good, not just have a force switch to print the entry.

I had a patch already, so hopefully this issue could be fixed soon.

[d-maurer]

Tian Gao wrote at 2024-5-31 13:26 -0700:

... The same thing could happen with post-mortem debugging as well - the user could potentially print something to help debugging, and if you print the stack entry before `.pdbrc` executes, it would be too far away. And this is not specific to post-mortem debugging, actually this is an issue for all cases involving `.pdbrc`. That's why I wanted to fix it for good, not just have a force switch to print the entry.

With post-mortem debugging, most commands (running, stepping, retval, continue, ...) are not useful. For other commands, it would not be a big problem if the stack entry is displayed before the cmd loop.

I had a patch already, so hopefully this issue could be fixed soon.

Okay, I will take a look at your solution.