After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 623552 - glib warns if backtrace.py is not present
glib warns if backtrace.py is not present
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 700736 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-07-04 21:59 UTC by Pacho Ramos
Modified: 2015-01-23 20:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (6.81 KB, patch)
2014-01-22 07:53 UTC, Tom Tromey
needs-work Details | Review
proposed patch (6.20 KB, patch)
2014-02-21 19:16 UTC, Tom Tromey
none Details | Review
gobject.py: Port to gdb 7.7 frame filter API (6.89 KB, patch)
2014-05-10 02:24 UTC, darkxst
committed Details | Review

Description Pacho Ramos 2010-07-04 21:59:57 UTC
We get the following:
Traceback (most recent call last):
  • File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2200.2-gdb.py", line 9 in <module>
    from gobject import register
  • File "/usr/share/glib-2.0/gdb/gobject.py", line 3 in <module>
    import gdb.backtrace
ImportError: No module named 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 )
Comment 1 Tom Tromey 2013-08-20 15:56:51 UTC
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.
Comment 2 Tom Tromey 2013-08-20 16:01:56 UTC
See also bug #700736 and bug #613732
Comment 3 Steve Tyler 2013-08-31 13:42:41 UTC
This problem has been reported by several Fedora users:

Bug 972351 - No module named backtrace 
https://bugzilla.redhat.com/show_bug.cgi?id=972351
Comment 4 Michael Catanzaro 2013-11-05 20:34:26 UTC
*** Bug 700736 has been marked as a duplicate of this bug. ***
Comment 5 Michael Catanzaro 2013-12-30 00:50:36 UTC
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.
Comment 6 darkxst 2014-01-05 06:50:08 UTC
The new upstream API is not very widespread right now, since its not available in a released gdb.
Comment 7 Tom Tromey 2014-01-22 07:53:52 UTC
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.
Comment 8 darkxst 2014-02-07 00:29:29 UTC
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
Comment 9 Tom Tromey 2014-02-07 02:35:54 UTC
(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.
Comment 10 darkxst 2014-02-08 02:11:07 UTC
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
Comment 11 Tom Tromey 2014-02-21 19:16:12 UTC
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:

  • #0 simple2_cb
    at signals.c line 903
  • #7 <emit signal 0x405a5c "simple-2" on instance 0x615aa0 [Test]>
    at gsignal.c line 3408
  • #8 test_invocation_hint
    at signals.c line 920

Comment 12 EMR_Gnome 2014-05-09 21:01:35 UTC
Has this been fixed? I am running F20 and need to do some backtraces
Comment 13 darkxst 2014-05-10 02:24:36 UTC
Created attachment 276272 [details] [review]
gobject.py: Port to gdb 7.7 frame filter API
Comment 14 darkxst 2014-05-10 02:26:22 UTC
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
Comment 15 Colin Walters 2014-05-10 09:34:14 UTC
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.
Comment 16 darkxst 2014-05-10 09:55:28 UTC
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..
Comment 17 Sergio 2014-06-30 08:10:36 UTC
(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 ?
Comment 18 Sergio 2014-06-30 14:38:42 UTC
#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,
Comment 19 Tyler Mace 2015-01-23 17:24:49 UTC
(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.
Comment 20 Michael Catanzaro 2015-01-23 20:23:40 UTC
(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. :)