Bug 972351 - No module named backtrace - for import gdb.backtrace - in File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
No module named backtrace - for import gdb.backtrace - in File "/usr/share/gl...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
20
Unspecified Linux
low Severity low
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: Reopened
: 1008746 1073284 1135789 (view as bug list)
Depends On:
Blocks: 1020004 1055733 1122154
  Show dependency treegraph
 
Reported: 2013-06-08 15:04 EDT by Thomas Meyer
Modified: 2015-02-03 16:10 EST (History)
48 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1055733 (view as bug list)
Environment:
Last Closed: 2015-02-03 16:10:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Adjusted patch for apply cleanly to (installed) glib2-devel-2.36.3-4.fc19.x86_64 (1.73 KB, patch)
2014-01-02 17:49 EST, Jan Pokorný
no flags Details | Diff
patch against the build tree (3.08 KB, patch)
2014-01-20 15:42 EST, Matěj Cepl
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 613732 None None None Never
GNOME Desktop 623552 None None None Never

  None (edit)
Description Thomas Meyer 2013-06-08 15:04:22 EDT
Description of problem:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.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
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.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


Version-Release number of selected component (if applicable):
Installierte Pakete
glib2.i686                                          2.36.2-1.fc19                                  @fedora  
glib2.x86_64                                        2.36.2-1.fc19                                  installed
glib2-devel.x86_64                                  2.36.2-1.fc19                                  installed

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Thomas Meyer 2013-07-08 17:30:13 EDT
closing as nobody seems to care.
Comment 2 Omair Majid 2013-07-31 12:24:23 EDT
I just ran into this too:

$ gdb java core.3897
GNU gdb (GDB) Fedora (7.6-32.fc19)
Copyright (C) 2013 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/>...
Reading symbols from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.x86_64/jre/bin/java...Reading symbols from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.x86_64/jre/bin/java...(no debugging symbols found)...done.
(no debugging symbols found)...done.
[New LWP 3898]
[New LWP 3918]
[New LWP 3899]
[New LWP 3900]
[New LWP 3922]
[New LWP 3901]
[New LWP 3952]
[New LWP 3902]
[New LWP 3954]
[New LWP 3903]
[New LWP 3957]
[New LWP 3904]
[New LWP 3956]
[New LWP 3905]
[New LWP 3906]
[New LWP 3907]
[New LWP 3908]
[New LWP 3909]
[New LWP 3911]
[New LWP 3912]
[New LWP 3913]
[New LWP 3914]
[New LWP 3915]
[New LWP 3919]
[New LWP 3950]
[New LWP 3953]
[New LWP 3955]
[New LWP 3958]
[New LWP 3959]
[New LWP 3897]
[New LWP 3910]
[New LWP 3960]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.x86_64/jre/bin/java -Dosgi.noShutdown='.
Program terminated with signal 6, Aborted.
#0  0x0000003198e35a19 in raise () from /lib64/libc.so.6
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-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
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-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
Missing separate debuginfos, use: debuginfo-install java-1.7.0-openjdk-1.7.0.25-2.3.10.4.fc19.x86_64

gdb-7.6-32.fc19.x86_64
glibc-2.17-11.fc19.x86_64
glib2-devel-2.36.3-2.fc19.x86_64
Comment 3 Steve Tyler 2013-08-06 12:52:01 EDT
Thomas, could you please reopen this bug? Some developers read bug reports, but do not comment, because they are busy. It would also help if you provided steps to reproduce. Your report is incomplete without such steps.

In the future, please fill in these sections of the bug report in addition to the ones you already filled in. The information you provide in these sections is very helpful to developers.

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
Comment 4 Steve Tyler 2013-08-06 12:56:13 EDT
Thomas, here is some information on writing bug reports:

Bug Writing Guidelines
https://bugzilla.redhat.com/page.cgi?id=bug-writing.html
Comment 5 Steve Tyler 2013-08-06 14:49:47 EDT
This upstream bug dated 2010-07-04 appears to be the same:

Bug 623552 - glib warns if backtrace.py is not present
https://bugzilla.gnome.org/show_bug.cgi?id=623552
Comment 6 Henrique Martins 2013-08-19 10:25:53 EDT
That is from 2010 and is still listed as UNCONFIRMED.
This other one from 2012, first Google hit, seems to point the finger at Fedora:
  http://sourceware.org/bugzilla/show_bug.cgi?id=14198
I was just trying to look at a core dump from libreoffice and got the same error. Process was
  gdb /path/to/soffice.bin /path/to/coredump
and it produces a couple of no gdb.backtrace complaints

Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-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
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-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

like in comment #2 above
Comment 7 Bobby Powers 2013-08-20 09:37:55 EDT
I see the same as Henrique in comment #6, and I suspect this is due to the opposite of the upstream bug 623552 mentioned by Steve - namely gdb 7.6 features refactored python libs, and the glib2 gdb support doesn't seem to have been updated yet.  I did a:

    $ find / -name 'backtrace.py' 2>/dev/null

On my box, and the only place I found it was in an old mock chroot that had gdb-7.5.50.20130310-13.fc19.x86_64 installed at /var/lib/mock/fedora-rawhide-x86_64/root/usr/share/gdb/python/gdb/backtrace.py .  /usr/share/gdb/python/gdb/ looks very different on my current f19 install.  I guess I can open a new bug up against glib2.
Comment 8 Steve Tyler 2013-08-20 11:03:38 EDT
Thanks, Bobby. That's very helpful. backtrace.py was indeed packaged with gdb until:

$ rpm -qi -p gdb-7.6-30.fc19.x86_64.rpm | grep 'Build Date'
Build Date  : Tue 21 May 2013 05:07:05 AM PDT

This commit, dated 2013-05-21, removed backtrace.py from the gdb package:

Backported Python frame filters (Phil Muldoon).
- Backported breakpoint conditions crash fix (Sergio Durigan Junior).
http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=89fbbfccaf093284eadb1af638486ee5b1701a81

CCing Jan for insight ...

==
Found with various incantations of koji:

$ koji download-build --arch=x86_64 gdb-7.5.50.20130310-13.fc19
...

$ rpm -ql -p gdb-7.5.50.20130310-13.fc19.x86_64.rpm | grep 'backtrace.py$'
/usr/share/gdb/python/gdb/backtrace.py
/usr/share/gdb/python/gdb/command/backtrace.py

$ koji list-untagged gdb | grep fc19
...

$ koji list-tagged f19 gdb
...

$ rpm -ql -p gdb-7.6-29.fc19.x86_64.rpm | grep 'backtrace.py$'
/usr/share/gdb/python/gdb/backtrace.py
/usr/share/gdb/python/gdb/command/backtrace.py

$ rpm -ql -p gdb-7.6-30.fc19.x86_64.rpm | grep 'backtrace.py$'
$
Comment 9 Jan Kratochvil 2013-08-20 11:15:47 EDT
glib2-devel-2.36.3-3.fc19.x86_64
gdb-7.6-34.fc19.x86_64

$ gdb gobject-query 
(gdb) run
Starting program: /usr/bin/gobject-query 
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-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
[...]

Phil, could you propose how to update /usr/share/glib-2.0/gdb/gobject.py ?
Comment 10 Phil Muldoon 2013-08-20 12:06:54 EDT
The frame filters API was ported upstream to GDB.  Unfortunatley to do
what we wanted to do with it, and in the confines of the upstream
projects we were not able to provide API compatability.  However,
the two are fairly close.  It should just take a few changes.  The
good news is, as this was rewritten for upstream, it now works
with MI.  Also as it is now upstream it is available outside of
Fedora, or other projects that do not carry the experimental archer
patch-set.  With the above in mind, the archer patch for the old frame
filters was dropped as it conflicts with the new feature.

There is a guide to writing frame filters from the GDB manual here:

http://sourceware.org/gdb/current/onlinedocs/gdb/Writing-a-Frame-Filter.html#Writing-a-Frame-Filter

As well as am API guide to the Frame filter, and Frame decorator
interface here:

http://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Filter-API.html#Frame-Filter-API

and

http://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Decorator-API.html#Frame-Decorator-API

As well as API changes, there are frame filter management commands
available to the user:

http://sourceware.org/gdb/current/onlinedocs/gdb/Frame-Filter-Management.html#Frame-Filter-Management

I would be happy to assist you in making the change in any way I can.
You can either bring issues up here, or on the gdb@sourceware.org
mailing list.

Cheers,

Phil
Comment 11 Steve Tyler 2013-08-20 15:57:25 EDT
Thanks, Jan and Phil.

Python integration with gdb is terrific technology, and I appreciate the work that has gone into it.

Phil: Since your changes break compatibility, could you do a search for any other Fedora components that might be affected?

(I'm not really sure how that would be done, but I have seen bug reports requesting changes along similar lines.)
Comment 12 Steve Tyler 2013-08-20 16:05:05 EDT
(In reply to Steve Tyler from comment #11)
...
> (I'm not really sure how that would be done, but I have seen bug reports
> requesting changes along similar lines.)

If there are a lot of affected components, a tracker bug could used.
Here is an example:
Bug 850016 - (systemd/Presets) Tracker bug for conversion to new systemd-rpm macros
Comment 13 Jan Kratochvil 2013-08-20 16:15:46 EDT
I do not think there is any other Fedora 19 user of backtrace.py.

repoquery -qal|grep /usr/share/gdb/auto-load
->
gdb-heap-0.5-12.fc19
glib2-devel-0:2.36.3-3.fc19
libreoffice-gdb-debug-support-1:4.1.0.4-6.fc19
libstdc++-0:4.8.1-1.fc19
->
grep -ri backtrace /usr/share/gdb-heap /usr/share/glib-2.0/gdb /usr/share/libreoffice/gdb /usr/share/gcc-4.8.1/python
->
/usr/share/glib-2.0/gdb/gobject.py
Comment 14 Richard W.M. Jones 2013-08-31 07:34:16 EDT
Still happening in Rawhide:

#0  output_type_enum (v=0xb9810590, obj=0x10, 
    strings=0xb7817ea0 <TpmType_lookup>, kind=0xb76c7dd0 "TpmType", name=0x0, 
    errp=0xbfa1ddf8) at qapi/qapi-visit-core.c:306
306	    int value = *obj;
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3705.0-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
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3705.0-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
Comment 15 Fedora End Of Life 2013-09-16 12:43:06 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 16 Jan Kratochvil 2013-09-17 01:36:26 EDT
*** Bug 1008746 has been marked as a duplicate of this bug. ***
Comment 17 Julian Sikorski 2013-10-20 12:41:43 EDT
*** Bug 1021118 has been marked as a duplicate of this bug. ***
Comment 18 Stas Sergeev 2013-10-30 15:27:05 EDT
Having the same problem.

Can someone please make the bug #1020004 (which
this one blocks) available? Currently it says
You are not authorized to access bug #1020004.
Comment 19 Jan Kratochvil 2013-10-30 15:28:51 EDT
There is nothing interesting, it is an internal Red Hat tracker.
Comment 20 Jeffrey C. Ollie 2013-11-04 11:12:29 EST
I am seeing this error in a backtrace of qgis - bug #1025778.
Comment 21 Miro Hrončok 2013-12-02 16:22:31 EST
Got the same error when locally analyzing openscad - bz1036898
Comment 22 Michael Catanzaro 2013-12-26 10:34:34 EST
There's an upstream patch at [1].  It doesn't use the new frame filters API, but does eliminate the error.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=613732
Comment 23 Jan Pokorný 2014-01-02 17:49:33 EST
Created attachment 844760 [details]
Adjusted patch for apply cleanly to (installed) glib2-devel-2.36.3-4.fc19.x86_64

Also stumbled upon this in F19 (in connection to [bug 822773 comment 10]).
Solved by "wiggling" the original patch (as it did not apply cleanly),
resulting in fitting patch as attached.  Worked for me.
Comment 24 Matěj Cepl 2014-01-20 15:42:35 EST
Created attachment 852842 [details]
patch against the build tree

This is a proper patch against our git
Comment 25 Jan Kratochvil 2014-01-20 15:47:46 EST
(In reply to Matěj Cepl from comment #24)
> This is a proper patch against our git

This is obviously wrong patch.  It disables the functionality when running on newer/recent GDB.  The proper patch should implement the same functionality on top of the new GDB Python API as described in Phil's Comment 10.
Comment 26 Matěj Cepl 2014-01-20 18:25:27 EST
(In reply to Jan Kratochvil from comment #25)
> This is obviously wrong patch.  It disables the functionality when running
> on newer/recent GDB.

Sorry, I didn't mean "proper" as in "providing the right solution of this problem", but just "it applies cleanly against our packaging repo". The previous patch by Jan Pokorný didn't. The error message and traceback just goes away, but of course, it is not the proper solution for this bug.
Comment 27 Jan Pokorný 2014-01-20 18:32:26 EST
(As I stated, "worked for me" -- in-place, w/o rebuild hassle, subsequently
in F20 ditto -- and easy to be picked up by anyone being after proper SRPM
patch, who should know what is going on anyway [not my case].)
Comment 28 Sergio Monteiro Basto 2014-02-14 17:47:12 EST
any work around I'm get ting this with:
firefox-gtk3 -g -d gdb
Comment 29 Jan Kratochvil 2014-02-25 14:29:05 EST
The proper fix is now upstream by Tom Tromey:
https://bugzilla.gnome.org/show_bug.cgi?id=623552#c11
Comment 30 Robert Kuska 2014-06-16 07:13:48 EDT
I can see that rawhide is updated, any chance getting new version of glib2 into f20?
Comment 31 Moez Roy 2014-06-29 23:24:59 EDT
[New LWP 23421]
[New LWP 23426]
[New LWP 23425]
[New LWP 23422]
[New LWP 23424]
[New LWP 23427]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.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

Timeout exceeded: 240 seconds, killing gdb.
Looks like gdb hung while generating backtrace.
This may be a bug in gdb. Consider submitting a bug report to gdb developers.
Please attach coredump from this crash to the bug report if you do.
Comment 32 Moez Roy 2014-06-29 23:27:04 EDT
*** Bug 1073284 has been marked as a duplicate of this bug. ***
Comment 33 Gwyn Ciesla 2014-07-22 14:07:40 EDT
I just hit this today on a fully updated f20, is this fix coming to f20?
Comment 34 Jan Kratochvil 2014-08-31 11:27:42 EDT
*** Bug 1135789 has been marked as a duplicate of this bug. ***
Comment 35 Michael Catanzaro 2015-02-03 16:10:24 EST
This is just a cosmetic error, it's not the cause of any problems you're having with gdb.

Note You need to log in before you can comment on or make changes to this bug.