Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
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 ourterms of service andprivacy 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
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Uh oh!
There was an error while loading.Please reload this page.
Co-authored-by: Tomas R. <tomas.roun8@gmail.com>
Misc/NEWS.d/next/Library/2025-02-24-01-49-11.gh-issue-82987.vHfQlG.rst OutdatedShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
| @@ -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.rstCo-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
Doc/library/pdb.rst Outdated
| 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 willalways be ignored if those areever 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 :)
63b6ec3 intopython:mainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
The testing code
seems a bit silly, but this is a real issue because we use thelast 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 wealways stop for inline breakpoints. The implementation I chose is to remove the condition for
opcodeevents 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.