homepage

I get a number of failures in test_gdb with gdb 7.0.1 about gdb.Frame, e.g.
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 538, 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: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

See my msg103440 of issue #8279.

According to documentation of the Python API of gdb, a frame has a function method. I read gdb 7.0, 7.0.1 and 7.1 (downloaded from http://ftp.gnu.org/gnu/gdb): there is not "function" method, but a "name" method.
On my Debiand Sid (gdb 7.1), gdb has the name method, but not the function method.
Can we use frame.name() instead of frame.function().name on any OS and all gdb 7.x versions?

The commit creating methods "function", "select" were added the 24th february 2010, whereas gdb 7.1 was released around the 18th february 2010.
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-frame.c?cvsroot=src
I guess that the author (Dave Malcolm?) of the is_evalframeex() method in Tools/gdb/libpython.py uses the HEAD version of GDB.
About the select() method, Dave added the following comment to its Frame wrapper:
---
 def select(self):
 '''If supported, select this frame and return True; return False if unsupported
 Not all builds have a gdb.Frame.select method; seems to be present on Fedora 12
 onwards, but absent on Ubuntu buildbot'''
---
gdb in Fedora 12 is based on 7.0.1 plus a lot of patches. But I don't see a patch added the select() method to the Python API:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/ 

Victor, please leave that to David. He will fix it.

If I'm reading this bug correctly, there are two issues here:
 
(A) that we shouldn't use gdb.Frame.function.name(), and should instead use gdb.Frame.name(). I believe this is a duplicate of issue 8279, and that this was fixed in trunk in r80156. It hasn't yet been fixed in the py3k branch; the patch from r80156 does appear to apply cleanly there.
(B) That different builds of gdb may or may not have gdb.Frame.select.
I'm attaching a patch to trunk which tries to autodetect whether the gdb.Frame.select method is present. The "py-up" and "py-down" commands and their selftest (StackNavigationTests) are made conditional upon this.
> gdb in Fedora 12 is based on 7.0.1 plus a lot of patches. But I don't see a patch added the
> select() method to the Python API:
> http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/
FWIW, the relevant patch is this one:
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-12/gdb-archer.patch?revision=1.40&view=markup
(search for "frapy_select" within that patch); as I understand it this generating from the git repository used by the team that created the Python support within gdb, and as such it's a snapshot of work, much of which is now in upstream gdb's CVS repository.

Assigning to loewis for review

> (A) that we shouldn't use gdb.Frame.function.name(), ...
> that this was fixed in trunk in r80156.
This command is not correct: it still calls .function() method:
 def is_evalframeex(self):
 '''Is this a PyEval_EvalFrameEx frame?'''
 if self._gdbframe.function():
 if self._gdbframe.name() == 'PyEval_EvalFrameEx':
Call to self._gdbframe.function() can be removed.
> The "py-up" and "py-down" commands and their selftest
> (StackNavigationTests) are made conditional upon this.
It's not enough, test_print_after_up() and test_locals_after_up() require also py-up command.
Attached patch is based on add-conditions-for-gdb.Frame.select-to-trunk.patch and fix described problems. Using test_gdb-2.patch, test_gdb pass without any error on my Debian Sid (gdb 7.1).

> Attached patch is based on add-conditions-for-gdb.Frame.select-to-
> trunk.patch and fix described problems. Using test_gdb-2.patch, test_gdb 
> pass without any error on my Debian Sid (gdb 7.1).
The patch conditionalizes each test within StackNavigationTests, but then drops it from the list of classes at the end. Looks like it needs to be reinstated.

Sorry about that.
Here's an updated version of the patch, combining my work with Victor's.

test_gdb pass with add-conditions-for-gdb.Frame.select-to-trunk-003.patch.
In a new patch, or maybe a last version of the add-.... patch, could you move all "main" code at the end? I found these instructions:
----
# register Python pretty printer
register (gdb.current_objfile())
# register commands
PyList()
if hasattr(gdb.Frame, 'select'):
 # Not all builds of gdb have gdb.Frame.select
 PyUp()
 PyDown()
PyBacktrace()
PyPrint()
PyLocals()
----
Could you also document how libpython.py is loaded automatically, and can I load it manually?
Anyway, thanks for libpython: it really rocks! I often use gdb with Misc/gdbinit, but pystack does not always work, and pyo crashs if Python is not yet initialized. It will be easier to improve the gdb scripting if it's written in Python!

Folks, can we please focus at one issue at a time? I'm not sure I understand the issue that this patch is supposed to fix; in any case, I can report that it doesn't fix *this* issue. I'm still getting the very same failures after applying the patch.
Victor, please don't hijack existing bug reports for new issues. If you have a new issue, create a new bug report. They are really cheap to get :-)

> I'm not sure I understand the issue that this patch is supposed 
> to fix
It should fix all test_gdb errors :-)
> in any case, I can report that it doesn't fix *this* issue. 
> I'm still getting the very same failures after applying the patch.
The "'gdb.Frame' object has no attribute 'function'" error? Could you copy/paste the output of test_gdb?
--
Sorry for the issue hijaking, I will open a new issue ;-)

I'm attaching the full output. It's the same as the one in the original report (msg103442) still.

> in any case, I can report that it doesn't fix *this* issue
Did you applied the patch version 3? The first version didn't fixed is_evalframeex(), but the version 3 does.
Could you retry with the last patch (version 3)?

Yes, I did try with version 3.

The patch does make a slight difference for me - I go from 14 failures down to 8 failures and 6 skipped.
The post-patch failures appear to be the same ones Martin is getting: "test_gdb.get_stack_trace" is regularly failing due to the lack of "gdb.Frame.function".

I don't understand because after applying the patch, there is not occurence of ".function" in Tools/gdb/libpython.py nor Lib/test/test_gdb.py.
Do you have an old python-gdb.py file in your Python root directory? I noticed that I had such file in my python trunk checkout and py3k checkout. This file was maybe renamed to Tools/gdb/libpython.py?
What is your OS and gdb versions?

> Do you have an old python-gdb.py file in your Python root directory?
Ah, ok. That was the problem indeed. The patch actually works fine.

Ah, yep - "rm python-gdb.py", "make" cleared up those remaining ".function" failures. The makefile could probably use a Modules/Setup.dist vs Modules/Setup style warning when libpython.py is newer than python-gdb.py to help prevent anyone else getting caught by that.
I still get one failure after that, even after a "make clean", "make", "./python -m test.regrtest -v test_gdb". Given the "unable to read Python frame information" embedded in the result on my machine (64-bit Kubuntu 9.10), it is probably related to the current issue.
The remaining failure:
======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests) 
Verify that the "py-bt" command works 
----------------------------------------------------------------------
Traceback (most recent call last): 
 File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 638, in test_basic_command 
 ''') 
 File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 158, in assertMultilineMatches 
 msg='%r did not match %r' % (actual, pattern)) 
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7532780, flags=1)\n at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n print(42)\n#7 (unable to read python frame information)\n#10 Frame 0x81a220, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)\n baz(a, b, c)\n#13 Frame 0x807f00, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)\n bar(a, b, c)\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#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \\(a=1, b=2, c=3\\)\n bar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \\(\\)\nfoo\\(1, 2, 3\\)\n'

In msg103780 Martin v. Löwis wrote:
> Ah, ok. That was the problem indeed. The patch actually works fine.
Good to hear. Thanks for tracking this down and clarifying it.
As I understand it, the current status of this bug is that file17000 fixes the reported issue, but hasn't yet been applied to trunk.
In msg103781 Nick Coghlan wrote:
> I still get one failure after that, even after a "make clean", "make", 
> "./python -m test.regrtest -v test_gdb". Given the "unable to read 
> Python frame information" embedded in the result on my machine (64-bit 
> Kubuntu 9.10), it is probably related to the current issue.
I believe this is a different issue; please can you open a separate bug about this. Reading the frame information seems to be highly sensitive to the optimization level and the exact version of gcc for the build, and the exact version of gdb, alas. I've been tracking a failure like the one you describe, seen on 64-bit with Fedora in our downstream tracker here:
https://bugzilla.redhat.com/show_bug.cgi?id=556975 

Fixed: r80289 (trunk), r80290 (py3k). I will check the buildbots :-)
Nick: Can you open a new issue for your last issue?
I will open a new issue for my suggestions. I also realized that gdb is missing in the documentation!

> Fixed: r80289 (trunk), r80290 (py3k). I will check the buildbots :-)
Please forgive my pedantry, but these appear to be off-by-one; the commits appear to have been:
r80288 (trunk), r80289 (py3k)

Remaining problem recorded as issue 8482 

(Oops, thought I had reverted those accidental edits by reloading the page. I guess not)