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. :)