GNOME Bugzilla – Bug 623552
glib warns if backtrace.py is not present
Last modified: 2015-01-23 20:23:40 UTC
We get the following: Traceback (most recent call last):
+ Trace 222694
from gobject import register
import gdb.backtrace
This shouldn't be shown since backtrace.py is not even an official module and is not provided by gdb upstream. Thanks for taking care (downstream report: http://bugs.gentoo.org/show_bug.cgi?id=291328 )
Upstream gdb has a new "frame filter" feature that obsoletes the old, unsupported backtrace.py. You can see the docs here: http://sourceware.org/gdb/current/onlinedocs/gdb/Writing-a-Frame-Filter.html (and elsewhere in the manual) This is new-ish in gdb so your python code will have to adapt.
See also bug #700736 and bug #613732
This problem has been reported by several Fedora users: Bug 972351 - No module named backtrace https://bugzilla.redhat.com/show_bug.cgi?id=972351
*** Bug 700736 has been marked as a duplicate of this bug. ***
With the resolution of Bug #613732, we no longer attempt to install the frame filter if backtrace.py is not present. But we should really be trying to use the upstream API instead.
The new upstream API is not very widespread right now, since its not available in a released gdb.
Created attachment 266953 [details] [review] proposed patch This patch changes gobject.py to use the new gdb frame filter feature. I tested it using the gobject "signals" test case. It works ok, though I noticed that the existing gobject.py code does not handle the fastpath signal emission case; I did not fix this bug. Note that this patch requires a very recent gdb; and furthermore that even today's git gdb has a few frame filter bugs that prevent this from working -- I got to debug those while developing this patch. The needed gdb fixes will be in the upcoming gdb 7.7 release, the first release with this feature. I tried to make the patch continue to work on older Fedora gdb, that includes the old gdb.backtrace feature. However, I did not test this. Alternatively I could remove the old code if you would prefer.
Review of attachment 266953 [details] [review]: I think it would make more sense to just drop the old gdb.backtrace support. Its not likely that glib 2.39 will be available anywhere that doesnt have gdb 7.7
(In reply to comment #8) > Review of attachment 266953 [details] [review]: > > I think it would make more sense to just drop the old gdb.backtrace support. > Its not likely that glib 2.39 will be available anywhere that doesnt have gdb > 7.7 Sounds good. I will write a new patch soon.
Review of attachment 266953 [details] [review]: ::: gobject/gobject.py @@ +201,3 @@ return "???" else: + return ' or '.join(set(itertools.imap(str, array))) itertools.imap won't work in Python3
Created attachment 269940 [details] [review] proposed patch Here is a new version of the patch. I left a bit of compatibility code for versions of gdb prior to 7.7. This seemed safest to me given that 7.7 was just released ~2 weeks ago. This code just arranges to disable the frame filter and, I think, is easy to maintain (and also remove when the time comes). However, it's certainly easy to remove it now should you prefer. I also fixed the imap problem that was pointed out; but I have not tried this code with Python 3. This version fixes a previously-existing bug where string.find's return value was improperly checked. Here's some sample output from the "signals" test case:
+ Trace 233204
Has this been fixed? I am running F20 and need to do some backtraces
Created attachment 276272 [details] [review] gobject.py: Port to gdb 7.7 frame filter API
Comment on attachment 276272 [details] [review] gobject.py: Port to gdb 7.7 frame filter API Fixed up patch to work with python 3 (it is still compatible with 2.6+) and cleaned up a bit
Review of attachment 276272 [details] [review]: This is hard to review as there's 2 variables (python 2,3 and gdb < 7.7, >= 7.7) resulting in 4 combinations, but eh...I'm assuming you've tested it, I don't see anything obviously wrong.
yes I tested python2,3 and gdb 7.7, gdb < 7.7 just gets disable although I couldnt test that! pushed, git bz baulked it, I suppose I don't have permissions to close up the bug, since it wasn't mine to start with? walters, can you mark fixed and committed etc..
(In reply to comment #12) > Has this been fixed? I am running F20 and need to do some backtraces I think the best way to fix Fedora 20 which have gdb-7.7 , is make the same patch for glib2-2.38.2 , please can you do it ?
#rpm -ql glib2-devel | grep py$ /usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3800.2-gdb.py /usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.2-gdb.py /usr/share/glib-2.0/codegen/__init__.py /usr/share/glib-2.0/codegen/codegen.py /usr/share/glib-2.0/codegen/codegen_docbook.py /usr/share/glib-2.0/codegen/codegen_main.py /usr/share/glib-2.0/codegen/config.py /usr/share/glib-2.0/codegen/dbustypes.py /usr/share/glib-2.0/codegen/parser.py /usr/share/glib-2.0/codegen/utils.py /usr/share/glib-2.0/gdb/glib.py /usr/share/glib-2.0/gdb/gobject.py I believe that we just need support for python-2.7.5 , in [1] is reported that we have this fixed in rawhide with glib2-2.41.x , but not with glib2-2.38.2 [1] https://bugzilla.redhat.com/show_bug.cgi?id=972351#c30 I'd reopen this bug if I had permissions , glib2 should support gdb-7.7 on previous versions , I think . Thanks,
(In reply to comment #18) > #rpm -ql glib2-devel | grep py$ > ... > > I believe that we just need support for python-2.7.5 , > in [1] is reported that we have this fixed in rawhide with glib2-2.41.x , but > not with glib2-2.38.2 > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=972351#c30 > > I'd reopen this bug if I had permissions , glib2 should support gdb-7.7 on > previous versions , I think . > > Thanks, I agree with Sergio, to make gdb work correctly in Fedora 20, there needs to be a patch. It's still a problem for what's out there.
(In reply to comment #19) > I agree with Sergio, to make gdb work correctly in Fedora 20, there needs to be > a patch. It's still a problem for what's out there. This was fixed last May; there's nothing more to be done here. If you use an older distro like Fedora 20 you can just ignore the error. This is just a cosmetic error, so if you're having a real problem with gdb, this bug is not the cause. :)