-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
eval frame rename in pep 0523 broke gdb's python extension #75166
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
Comments
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 change broke test_gdb on most buildbots :-( ====================================================================== Traceback (most recent call last):
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_gdb.py", line 688, in test_pyup_command
$''')
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_gdb.py", line 259, in assertMultilineMatches
self.fail(msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=self@entry=, v=42) at Python/bltinmodule.c:1103\n1103\t{\n#4 Frame 0x4086b4cc, for file /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n id(42)\n#5 Frame 0x4086b4cc, for file /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n id(42)\n' did not match '^.*\n#[0-9]+ Frame 0x-?[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n baz\\(a, b, c\\)\n$' |
I chose to revert the change because I don't have the bandwidth right now to investigate why the change broke test_gdb. I'm surprised that a change affecting python-gdb.py wasn't properly tested manually using test_gdb.py :-( I understand that Travis CI doesn't have gdb and/or that the test pass in some cases? The revert only gives us more time to design the proper solution. |
In this case it would be great if the buildbots commented on the relevant pull request that it broke the build. Otherwise this creates this dissonance that it was all green during merging of the PR when in fact it wasn't. I think we need to make test_gdb run on Travis, this is an unfortunate omission. |
While our CI is getting better everyday, it still has a few flaws. There is no automated buildbot failure notification to the author and In the meanwhile I check manually buildbots output and report bugs and For gdb, don't worry, the buildbots were fixed quickly, it's fine if the |
I am unable to repro this locally. With the changes to libpython.py test_gdb still passes on CentOS 7 and macOS 10.12. |
OK, I got the repro. You have to rebuild python for /Tools/gdb/libpython.py to land in /python-gdb.py. The latter is used during test_gdb.py. |
Ah yes, sorry, that's not obvious. "make" does the copy for you. |
The issue originally stems from the fact that a non-debug Python build with --enable-shared is inlining PyEval_EvalFrameEx into _PyEval_EvalFrameDefault. So, the patch should really become to *replace* discovering PyEval_EvalFrameEx with the discovery of _PyEval_EvalFrameDefault. This might be problematic in the future when there is an actual JIT but currently it's strictly better than the current situation where the gdb bindings simply don't work for shared builds. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: