-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
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
gh-82987: Stop on calling frame unconditionally for inline breakpoints #130493
Conversation
Co-authored-by: Tomas R. <[email protected]>
Misc/NEWS.d/next/Library/2025-02-24-01-49-11.gh-issue-82987.vHfQlG.rst
Outdated
Show resolved
Hide resolved
@@ -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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
…fQlG.rst Co-authored-by: Irit Katriel <[email protected]>
Doc/library/pdb.rst
Outdated
@@ -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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
There was a problem hiding this comment.
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 :)
The testing code
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 innocentbreakpoint()
, 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 likeuntil instruction
. Always trigger user function for opcode seems like an okay solution.