-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
bpo-22577: in pdb, prevent changes to locals from being lost after a jump #11041
Conversation
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
Wouldn't this leave the actual locals used in downstream code inconsistent with that reported by pdb? FWIW, pdb is consistent with the way assignments to locals() are handled in regular functions:
It is the nature of locals to not be guaranteed to be updatable. |
LGTM @rhettinger this problem is not related to the locals() function and is specific to pdb: The example in bpo-22577, that this PR is referring to, illustrates the problem: the value of x, assigned to within a pdb session, is different whether the pdb jump command is used or not. |
Oops ! This change introduces a regression (missed because it seems there is no pdb test on the change of a local variable). With the change, pdb prints
The test added by the PR succeeds because the following pdb commands occur in the same interaction, i.e. within the same python trace function, and do not test the changes occuring in frame->f_locals:
|
Thanks for the catch! I will add the regression test to the PR and work on a solution. Any insight on approach would be appreciated. |
IMHO the copy of However |
I confirmed that the proposed implementation of PEP 558 fixes the bug. Hence I'm closing this PR. |
The
Pdb.setup
method creates acurframe_locals
attribute to prevent subsequent.f_locals
access from undoing changes made during the debugging session. However, the existing implementation bindscurframe_locals
to.f_locals
without making a copy, so changes are lost after a jump because it invokes theBdb.format_stack_entry
method which does contain an.f_locals
access.The proposed fix is to assign to
curframe_locals
a copy of.f_locals
.I've added a test to
test_pdb
that reproduces the original issue.https://bugs.python.org/issue22577