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

[d-maurer]

Bug report

Bug description:

pdb.post_mortem used to display the current stack entry before the command loop (which has been useful). With Python 3.13, this is no longer the case when there is a .pdbrc file.
The reason is the following code in pdb.Pdb.interaction:

            # if we have more commands to process, do not show the stack entry
            if not self.cmdqueue:
                self.print_stack_entry(self.stack[self.curindex])

If a .pdbrc exists, self.cmdqueue contains the commands from this file and the current stack entry is not displayed.

I suggest the introduction of a new interaction parameter show_stack_entry (with default False) and to display the current stack entry if it has a true value. Set it to True in the _post_mortem call of interaction.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-119824: Print stack entry when user input is needed #119882
• [3.13] gh-119824: Print stack entry when user input is needed (GH-119882) #120533
• [3.12] gh-119824: Print stack entry when user input is needed … #120594
• [3.13] gh-119824: Revert the where solution and use meta commands #120919
• [3.12] gh-119824: Revert the where solution and use meta commands #120928

[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.

[gaogaotiantian]

This is fixed in main, 3.13 and 3.12. Let me know if you still have the issue.

[d-maurer]

Tian Gao wrote at 2024-6-23 17:21 -0700:

This is fixed in main, 3.13 and 3.12. Let me know if you still have the issue.

Thank you! I like your introduction of the `count` parameter of `where` as well: it will be very helpful!