GDB macros in Misc/gdbinit are broken
I have opened an issue on b.p.o., [1] but I wonder whether Misc/gdbinit is still supported in 3.6. [1]: http://bugs.python.org/issue29673
I suggest to remove them. I didn't use them since python-gdb.py exist. Does someone still need gdbinit macros for gdb without python binding? Victor Le 28 févr. 2017 1:27 AM, "Alexander Belopolsky" < alexander.belopolsky@gmail.com> a écrit :
I have opened an issue on b.p.o., [1] but I wonder whether Misc/gdbinit is still supported in 3.6.
[1]: http://bugs.python.org/issue29673
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ victor.stinner%40gmail.com
Alexander> I find them useful. I've never had success with python-gdb.py. As the original author, and occasional user (just in the last week or two) I still find the current crude hack useful. I tried to get the Python support in GDB working a couple years ago, but gave up in frustration. I hope it's better now. I added a comment to Alexander's bug report. Skip
2017-02-28 3:00 GMT+01:00 Skip Montanaro <skip.montanaro@gmail.com>:
Alexander> I find them useful. I've never had success with python-gdb.py.
Alexander, Skip: Oh, which kind of issues do you have with python-gdb.py? It doesn't work? You are unable to dump some data? python-gdb.py doesn't run code to analyze memory, it prevents crashes when analysing a running process, and it works on core dumps. It has many features, it works well. I never had major issues with it, and I enhance it regulary. Recently, I added support for "method-wrapper". Victor
I haven't tried using Python support in gdb in a long time. I don't know what python-gdb.py is. How is that different than Tools/gdb/libpython.py? Is it distributed with Python? (I'm kind of blind at work without a source distribution I can grep through, and didn't see it in Tools/gdb or Misc.) I'm a simple man. I need the kind of stuff Misc/gdbinit provides (smart stack traces and variable printing), but I most frequently use the pyo user-defined command to print the contents of PyObject pointers. When they are working (<wink>) pystack and pyframe are also useful. Skip On Tue, Feb 28, 2017 at 2:33 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2017-02-28 3:00 GMT+01:00 Skip Montanaro <skip.montanaro@gmail.com>:
Alexander> I find them useful. I've never had success with python-gdb.py.
Alexander, Skip: Oh, which kind of issues do you have with python-gdb.py? It doesn't work? You are unable to dump some data?
python-gdb.py doesn't run code to analyze memory, it prevents crashes when analysing a running process, and it works on core dumps. It has many features, it works well. I never had major issues with it, and I enhance it regulary. Recently, I added support for "method-wrapper".
Victor
On Feb 28, 2017, at 09:09 AM, Skip Montanaro wrote:
I haven't tried using Python support in gdb in a long time. I don't know what python-gdb.py is. How is that different than Tools/gdb/libpython.py? Is it distributed with Python? (I'm kind of blind at work without a source distribution I can grep through, and didn't see it in Tools/gdb or Misc.)
I'm a simple man. I need the kind of stuff Misc/gdbinit provides (smart stack traces and variable printing), but I most frequently use the pyo user-defined command to print the contents of PyObject pointers. When they are working (<wink>) pystack and pyframe are also useful.
I think I'm largely in the same boat as Skip although it's been a while since I stepped through the C code. I also had trouble (ages ago) getting the gdb integration working, so I relied on the simple stuff in gdbinit. I think there's still utility in that if we can keep it working. -Barry
On Tue, Feb 28, 2017 at 3:33 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Alexander, Skip: Oh, which kind of issues do you have with python-gdb.py? It doesn't work? You are unable to dump some data?
First, I had to rename python-gdb.py to python3.6-gdb.py to make it load. Then running backtrace gave me a bunch of error messages: (gdb) bt #0 builtin_hex (module=<module at remote 0x7ffff1a69c58>, number=0) at Python/bltinmodule.c:1436 #1 0x00007ffff7a9304c in _PyCFunction_FastCallDict (func_obj=<built-in method hex of module object at remote 0x7ffff1a69c58>, args=0x662cf8, nargs=1, kwargs=0x0) at Objects/methodobject.c:209 #2 0x00007ffff7a9344b in _PyCFunction_FastCallKeywords (func=<built-in method hex of module object at remote 0x7ffff1a69c58>, stack=0x662cf8, nargs=1, kwnames=0x0) at Objects/methodobject.c:295 #3 0x00007ffff7bac6d9 in call_function (pp_stack=0x7fffffffb6d8, oparg=1, kwnames=0x0) at Python/ceval.c:4788 #4 0x00007ffff7ba3e6c in _PyEval_EvalFrameDefault (f=Frame 0x662b68, for file r.py, line 2, in <module> (), throwflag=0) at Python/ceval.c:3275 #5 0x00007ffff7b8cc67 in PyEval_EvalFrameEx (f=Frame 0x662b68, for file r.py, line 2, in <module> (), throwflag=0) at Python/ceval.c:718 #6 0x00007ffff7ba9745 in _PyEval_EvalCodeWithName (_co=<code at remote 0x7ffff1983f40>, globals=Traceback (most recent call last): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 1358, in to_string return pyop.get_truncated_repr(MAX_OUTPUT_LEN) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 243, in get_truncated_repr self.write_repr(out, set()) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 702, in write_repr for pyop_key, pyop_value in self.iteritems(): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 669, in iteritems entries, nentries = self._get_entries(keys) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 717, in _get_entries except gdb.error: AttributeError: 'module' object has no attribute 'error' ... It looks like there is a mismatch between python-gdb.py and the gdb module that I assume comes with gdb. $ gdb --version GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6) ..
First, I had to rename python-gdb.py ...
Okay, I found a copy of python-gdb.py at the top level in a 2.7.13 snapshot I have at-hand. I have no idea where it came from. A file search on GitHub in the python/cpython repo on both master and 2.7 branches yielded nothing. It does seem to be working for me on a debug build of Python 2.7.13 (I ran strings over my GDB executable first to see if it knew anything about Python, and it did). Thx, Skip
2017-02-28 20:38 GMT+01:00 Alexander Belopolsky <alexander.belopolsky@gmail.com>:
First, I had to rename python-gdb.py to python3.6-gdb.py to make it load.
There is nothing specific to Python here, the file command of gdb (or gdb file) tries to load "file-gdb.py". So if your program is called python3.6, gdb looks for python3.6-gdb.py, yeah.
Then running backtrace gave me a bunch of error messages: (...) except gdb.error: AttributeError: 'module' object has no attribute 'error'
Oh, I never tried python-gdb.py on RHEL. Sadly, I know that the Python binding of gdb changes depending on the gdb version, but I also suspect that it changes depending on the OS! I'm quite sure that Fedora backports gdb changes for its Python API. I'm only using python-gdb.py on Fedora, usually even the latest Fedora version. Fedora always has bleeding edge versions of development tools! It shouldn't be hard to catch this "except gdb.error:" line. We should find the right exception and patch libpython.py.
It looks like there is a mismatch between python-gdb.py and the gdb module that I assume comes with gdb.
python-gdb.py (libpython.py) should work on any gdb version. It shouldn't be hard to support multiple gdb versions in same code base, we already support Python 2 and Python 3 in the same code base! (Depending on the OS and OS version, gdb may use Python 2 or Python 3 to run python-gdb.py, this script is run by gdb, not by test debugged Python binary! ;-)) Victor
Ok, it seems like very few people know how to use python-gdb.py :-/ Sorry, I expect that everybody was using it! python-gdb.py was written by Dave Malcolm, it includes: * a pretty printer for many builtin Python types: str, tuple, list, dict, frame, etc. It means that a regular gdb "print obj" command displays the Python object content instead of a raw pointer. This feature is super useful, it avoids to call _PyObject_Dump(obj) which is likely to crash! * commands to navigate between Python frames: py-up, py-down * command to dump the Python traceback: py-bt, py-bt-full (also include C frames) * a few more commands For me, these commands are really amazing! It's impressive to be able to that in a debugger which doesn't know Python internals at all! It's cool to be able to "program" (extend) a debugger! I never tried to install it, I always use it with a ./python binary compiled in the source code tree: --- $ make $ gdb ./python # load ./python-gdb.py ... --- Note: ./python-gdb.py is simply a copy of Tools/gdb/libpython.py, copied by Makefile. On Fedora, gdb doesn't load python-gdb.py because it doesn't trust my $HOME/prog directory (root of all my development directories). I had to trust it using this ~/.gdbinit config: --- add-auto-load-safe-path ~/prog/ --- More generally, when gdb loads a "program", it tries to load "program-gdb.py" in the same directory. Maybe it can load "program-gdb.py" from other directories, but I never understood this part, and hopefully I never had to understand it :-D Maybe the debug package of Python on Debian and Fedora installs pythonX.Y-gdb.py in the right directory, I didn't check, but I always debug using a freshly compiled Python, so I never tried to understand how these things work. Example: ---- haypo@selma$ gdb ./python (gdb) b _PyEval_EvalFrameDefault (gdb) run Breakpoint 1, _PyEval_EvalFrameDefault ( f=Frame 0x7ffff7f22058, for file <frozen importlib._bootstrap>, line 25, in <module> (), throwflag=0) at Python/ceval.c:678 678 PyObject *retval = NULL; /* Return value */ => gdb displays the content of the frame "f", you can see immediately the filename and the line number (well, this frame is a little bit special, it's the frozen module importlib) (gdb) py-bt Traceback (most recent call first): File "<frozen importlib._bootstrap>", line 25, in <module> --- Example of Python traceback: ---- haypo@selma$ gdb -args ./python -m test -r (gdb) run ... ^C (gdb) py-bt Traceback (most recent call first): File "/home/haypo/prog/python/master/Lib/test/test_long.py", line 947, in test_bit_length self.assertEqual(k, len(bin(x).lstrip('-0b'))) File "/home/haypo/prog/python/master/Lib/unittest/case.py", line 601, in run testMethod() File "/home/haypo/prog/python/master/Lib/unittest/case.py", line 649, in __call__ return self.run(*args, **kwds) File "/home/haypo/prog/python/master/Lib/unittest/suite.py", line 122, in run test(result) File "/home/haypo/prog/python/master/Lib/unittest/suite.py", line 84, in __call__ return self.run(*args, **kwds) ... => you get filename, line number, function name and even the Python line! It seems obvious to get such information, but remind that you are in gdb, not in Python (gdb) py-list 942 def test_bit_length(self): 943 tiny = 1e-10 944 for x in range(-65000, 65000): 945 k = x.bit_length() 946 # Check equivalence with Python version
947 self.assertEqual(k, len(bin(x).lstrip('-0b'))) 948 # Behaviour as specified in the docs 949 if x != 0: 950 self.assertTrue(2**(k-1) <= abs(x) < 2**k) 951 else: 952 self.assertEqual(k, 0)
# move to the parent Python frame (= skip mutiple C frames until the next Python frame) (gdb) py-up (...) (gdb) py-list 596 with outcome.testPartExecutor(self): 597 self.setUp() 598 if outcome.success: 599 outcome.expecting_failure = expecting_failure 600 with outcome.testPartExecutor(self, isTest=True):
601 testMethod() 602 outcome.expecting_failure = False 603 with outcome.testPartExecutor(self): 604 self.tearDown() 605 606 self.doCleanups()
(gdb) py-locals self = <LongTest(_testMethodName='... result = <TestResult(... testMethod = <method at remote 0x7fffe8bf4d78> expecting_failure_method = False expecting_failure_class = False expecting_failure = False ... => dump all variables of the current Python frame! -------- Victor
participants (4)
-
Alexander Belopolsky -
Barry Warsaw -
Skip Montanaro -
Victor Stinner