| msg102070 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2010-04-01 07:47 |
| regrtest reports ====================================================================== FAIL: test_basic_command (test.test_gdb.PyListTests) Verify that the "py-list" command works ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/martin/work/27/Lib/test/test_gdb.py", line 518, in test_basic_command cmds_after_breakpoint=['py-list']) File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace self.assertEquals(err, '') AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != '' ====================================================================== FAIL: test_one_abs_arg (test.test_gdb.PyListTests) Verify the "py-list" command with one absolute argument ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/martin/work/27/Lib/test/test_gdb.py", line 535, in test_one_abs_arg cmds_after_breakpoint=['py-list 9']) File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace self.assertEquals(err, '') AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != '' ====================================================================== FAIL: test_two_abs_args (test.test_gdb.PyListTests) Verify the "py-list" command with two absolute arguments ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/martin/work/27/Lib/test/test_gdb.py", line 548, in test_two_abs_args cmds_after_breakpoint=['py-list 1,3']) File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace self.assertEquals(err, '') AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != '' ---------------------------------------------------------------------- |
|
|
| msg102071 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-01 07:49 |
| The other failures look similar, so I'm not reporting them separately for now. |
|
|
| msg102102 - (view) |
Author: Dave Malcolm (dmalcolm) |
Date: 2010-04-01 16:05 |
| Thanks for reviewing the gdb work. I was mistakenly testing using: make ; ./python Lib/test/test_gdb.py which led to path assumptions in the code. I'm now testing with: make ; ./python Lib/test/regrtest.py -v test_gdb I'm attaching a patch which uses test_support.findfile to locate the test script; the code now works when invoked using either of the above: $ ./python Lib/test/regrtest.py test_gdb test_gdb 1 test OK. [39894 refs] There was also some breakage of the PyListTests due to significant trailing whitespace within the multiline string containing the expected result. The trailing whitespace was stripped in test_gdb.py. I've rewritten these multiline string literals as adjacent single-line string literals, so that this significant whitespace is explicit. (The output of each line has the line number, then four spaces, then the content of the line from the source file. An empty source line thus has the number followed by four trailing spaces.) I've also slightly changed the regex in get_gdb_repr() that carves up what GDB prints, since gdb can insert newlines and spaces in a somewhat arbitrary way, apparently based on the width of the tty that its stdout is connected to. The tests were passing when run from a full-screen terminal, but some would fail if I resized the terminal to 80 columns (!). I've tested the new code at both terminal sizes, and piping to "cat" (so that it's not at tty), and all tests now pass for all three cases. |
|
|
| msg102118 - (view) |
Author: Dave Malcolm (dmalcolm) |
Date: 2010-04-01 18:11 |
| I'm attaching a revised version of the patch; this is as before, but takes account of the rename of the sample file from "test_gdb_sample.py" to "gdb_sample.py" in r79557. |
|
|
| msg102237 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-03 11:25 |
| I still get failures, after applying . I'm attaching the complete regrtest output. |
|
|
| msg102276 - (view) |
Author: Dave Malcolm (dmalcolm) |
Date: 2010-04-03 15:37 |
| It looks like all of the failures were due to gdb.Frame not having a "function" method. I did some digging, and it appears that this attribute may not yet be in the upstream version of gdb. The gdb/python integration was largely implemented by colleagues of mine at Red Hat, and Fedora's build of gdb is closely tracking their work. It looks to me like only a subset of their work has been merged into upstream gdb so far. Specifically http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer.patch?revision=1.40&view=markup (warning: large) contains a hunk that applies to gdb/python/py-frame.c which adds "frapy_function". So it appears that I've unwittingly coded this to a very recent pre-merge version of gdb. Sorry about this. What is the output of "gdb --version" on this machine? What happens if you run: $ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)" For reference, on Fedora 12 I see: [david@surprise ~]$ gdb --version GNU gdb (GDB) Fedora (7.0.1-33.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. [david@surprise ~]$ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)" <method 'function' of 'gdb.Frame' objects> ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'block', 'find_sal', 'function', 'is_valid', 'name', 'newer', 'older', 'pc', 'read_var', 'select', 'type', 'unwind_stop_reason'] On Fedora 13: [david@f13 ~]$ gdb --version GNU gdb (GDB) Fedora (7.0.50.20100203-15.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. [david@f13 ~]$ gdb --batch --eval-command "python print gdb.Frame.function" --eval-command "python print dir(gdb.Frame)" <method 'function' of 'gdb.Frame' objects> ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'block', 'find_sal', 'function', 'is_valid', 'name', 'newer', 'older', 'pc', 'read_var', 'select', 'type', 'unwind_stop_reason'] The code works for me on both of these machines; all tests pass. Assuming that my analysis above is correct, then I'd expect other builds of gdb not to have the gdb.Frame.function method. This method is critical for the libpython.py:Frame class, and so without it the various extension commands aren't going to be usable. The pretty-printers ought to still work. The fix would be to detect the presence of gdb.Frame.function, and enable/disable the commands and their selftests accordingly, assuming that it's OK to add a conditional dependency on code that isn't merged into gdb's trunk yet. I'll do a patch for this. |
|
|
| msg102279 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-03 15:45 |
| > What is the output of "gdb --version" on this machine? GNU gdb (GDB) 7.0.1-debian This GDB was configured as "x86_64-linux-gnu". The debian package is 7.0.1-2 > $ gdb --batch --eval-command "python print gdb.Frame.function" > --eval-command "python print dir(gdb.Frame)" Traceback (most recent call last): File "", line 1, in AttributeError: type object 'gdb.Frame' has no attribute 'function' Error while executing Python code. ['__class__', '__delattr__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'is_valid', 'name', 'newer', 'older', 'pc', 'read_var', 'type', 'unwind_stop_reason'] > The fix would be to detect the presence of gdb.Frame.function, and > enable/disable the commands and their selftests accordingly, assuming > that it's OK to add a conditional dependency on code that isn't > merged into gdb's trunk yet. That would be fine, I think. Please add a comment saying that gdb 7.0.1 didn't have this feature yet. |
|
|
| msg102313 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2010-04-04 01:25 |
| This may be related to test_gdb problems I am seeing (test_gdb output attached). gdb details: GNU gdb (GDB) 7.0-ubuntu This GDB was configured as "x86_64-linux-gnu". After applying Dave's second patch, those original errors go away, but I get a lot of failures of the form: AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\nError occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != '' (Will upload the test output for the second patch shortly - I'm out of town for the next couple of days, so I won't be able to look at this again until next week) |
|
|
| msg102314 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2010-04-04 01:33 |
| Second error log attached (and the MIME type should finally be set properly to let it display as a text file in the browser) |
|
|
| msg102916 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-12 05:14 |
| The patch in was applied as part of . |
|
|
| msg103185 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-15 05:28 |
| Dave, file 16727 fails to apply, but apparently still contains necessary pieces. Can you please provide an updated version of the patch against the trunk? |
|
|
| msg103240 - (view) |
Author: Dave Malcolm (dmalcolm) |
Date: 2010-04-15 18:02 |
| New version of patch attached All tests continue to pass for me. I believe this will fix the "py-list", "py-locals", "py-print" commands and their respective tests on Ubuntu; I expect py-up/py-down to still fail due to missing gdb.Frame.select method. |
|
|
| msg103438 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-04-17 21:53 |
| #8434 is a duplicate of this issue. |
|
|
| msg103440 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-04-17 22:34 |
| In GDB 7.1, a gdb.frame object has no more function method: it's replaced by a name method. Tools/gdb/libpython.py should be modified: Add >>GDB_70 = gdb.VERSION.startswith("7.0")<< at the beginning, and replace is_evalframeex() by: def is_evalframeex(self): '''Is this a PyEval_EvalFrameEx frame?''' if GDB_70: func = self._gdbframe.function() if not func: return False func_name = func.name else: func_name = self._gdbframe.name() if func_name != 'PyEval_EvalFrameEx': return False # I believe we also need to filter on the inline # struct frame_id.inline_depth, only regarding frames with # an inline depth of 0 as actually being this function # # So we reject those with type gdb.INLINE_FRAME return (self._gdbframe.type() == gdb.NORMAL_FRAME) |
|
|
| msg103441 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-04-17 22:42 |
| Thanks for the patch, committed as r80156. As expected, there are still complaints about gdb.Frame. As the original issue is now resolved, I'm closing this issue as fixed, and open a new issue for the remaining failures. |
|
|
| msg103445 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-04-17 23:05 |
| > In GDB 7.1, a gdb.frame object has no more function method (...) Missing function method is not related to gdb version: see #8437 (). As Martin wrote: let's continue the discussion in issue #8437 ;-) |
|
|