Skip to content

gh-82987: Stop on calling frame unconditionally for inline breakpoints #130493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

gaogaotiantian
Copy link
Member

@gaogaotiantian gaogaotiantian commented Feb 24, 2025

The testing code

import pdb
def foo():
    x = 40 + 2
    pdb.Pdb(skip=['__main__']).set_trace()
foo()

seems a bit silly, but this is a real issue because we use the last instance of pdb for inline breakpoints now.

So if we instantiate a debugger like p = pdb.Pdb(skip=["django.*"]) somewhere, and we set an inline breakpoint in Django with an innocent breakpoint(), it still won't stop inside Django modules.

Overall I think it's reasonable that we always stop for inline breakpoints. The implementation I chose is to remove the condition for opcode events which also makes sense. For now that event is exclusively used by inline breakpoints. Even if we add instruction level debugging in the future, I think the only useful command is "step instruction". It's hard to imagine instruction level breakpoints or something like until instruction. Always trigger user function for opcode seems like an okay solution.

Co-authored-by: Tomas R. <[email protected]>
@@ -0,0 +1 @@
:mod:`pdb` will always stop on calling frames when inline breakpoints like :func:`breakpoint` or :func:`pdb.set_trace` are used, regardless of whether the module matches ``skip`` pattern.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably worth a what's new entry.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And a versionchange comment in the doc?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -245,6 +245,9 @@ access further features, you have to do this yourself:
.. versionadded:: 3.14
Added the *mode* argument.

.. versionchanged:: 3.14
*skip* will be ignored if inline breakpoints like :func:`breakpoint` or :func:`set_trace` are used.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"if ... are used" could be misunderstood to mean that skip will always be ignored if those are ever used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will changing it to "when ... are used" better? Or we should just use the longer version from the news entry?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "when .. are used" has the same problem, as does the longer version from the news entry.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline breakpoints like :func:`breakpoint` or :func:`pdb.set_trace` will always stop the program at calling frame, ignoring the ``skip`` pattern (if any).

Is this better?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I'll use this for all 3 places :)

@gaogaotiantian gaogaotiantian merged commit 63b6ec3 into python:main Mar 4, 2025
43 checks passed
@gaogaotiantian gaogaotiantian deleted the breakpoint-stop-unconditionally branch March 4, 2025 16:58
seehwan pushed a commit to seehwan/cpython that referenced this pull request Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants