-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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-30983: eval frame rename in pep 0523 broke gdb's python extension #2803
Conversation
pep 0523 renames PyEval_EvalFrameEx to _PyEval_EvalFrameDefault while the gdb python extension only looks for PyEval_EvalFrameEx to understand if it is dealing with a frame. Final effect is that attaching gdb to a python3.6 process doesnt resolve python objects. Eg. py-list and py-bt dont work properly. This patch fixes that. Tested locally on python3.6
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 our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. Thanks again to your contribution and we look forward to looking at it! |
My first python upstream patch. PSF contributor agreement signed |
if self._gdbframe.name() == 'PyEval_EvalFrameEx': | ||
'''Is this a PyEval_EvalFrameEx or _PyEval_EvalFrameDefault (PEP 0523) | ||
frame?''' | ||
if self._gdbframe.name() in ('PyEval_EvalFrameEx', |
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.
Should PyEval_FrameEx
even stay as an option if this simply won't work if someone sets a eval frame function? I mean if the gdb support is so reliant on the specifics of PyEval_EvalFrameDefault
then maybe it isn't worth trying to support PyEval_EvalFrameEx
?
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.
We want to keep the old name because the same python-gdb.py can be used to debug also older Python core dumps. We even keep the syntax compatible with 2.6 for it to be linkable with older gdbs. There's a comment on the top:
# NOTE: some gdbs are linked with Python 3, so this file should be dual-syntax
# compatible (2.6+ and 3.0+). See #19308.
Thanks! ✨ 🍰 ✨ |
GH-3090 is a backport of this pull request to the 3.6 branch. |
…ension (pythonGH-2803) pep 0523 renames PyEval_EvalFrameEx to _PyEval_EvalFrameDefault while the gdb python extension only looks for PyEval_EvalFrameEx to understand if it is dealing with a frame. Final effect is that attaching gdb to a python3.6 process doesnt resolve python objects. Eg. py-list and py-bt dont work properly. This patch fixes that. Tested locally on python3.6 (cherry picked from commit 2e0f4db)
…ension (GH-2803) (#3090) pep 0523 renames PyEval_EvalFrameEx to _PyEval_EvalFrameDefault while the gdb python extension only looks for PyEval_EvalFrameEx to understand if it is dealing with a frame. Final effect is that attaching gdb to a python3.6 process doesnt resolve python objects. Eg. py-list and py-bt dont work properly. This patch fixes that. Tested locally on python3.6 (cherry picked from commit 2e0f4db)
pep 0523 renames PyEval_EvalFrameEx to _PyEval_EvalFrameDefault while the gdb python extension only looks for PyEval_EvalFrameEx to understand if it is dealing with a frame.
Final effect is that attaching gdb to a python3.6 process doesnt resolve python objects. Eg. py-list and py-bt dont work properly.
This patch fixes that. Tested locally on python3.6