Bug 972351

closing as nobody seems to care.

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

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:

Thomas, here is some information on writing bug reports:

Bug Writing Guidelines
https://bugzilla.redhat.com/page.cgi?id=bug-writing.html

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

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

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.

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$'
$

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 ?

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
mailing list.

Cheers,

Phil

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

(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

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

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

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

*** Bug 1008746 has been marked as a duplicate of this bug. ***

*** Bug 1021118 has been marked as a duplicate of this bug. ***

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.

There is nothing interesting, it is an internal Red Hat tracker.

I am seeing this error in a backtrace of qgis - bug #1025778.

Got the same error when locally analyzing openscad - bz1036898

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

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.

Created attachment 852842 [details]
patch against the build tree

This is a proper patch against our git

(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.

(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.

(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].)

any work around I'm get ting this with:
firefox-gtk3 -g -d gdb

The proper fix is now upstream by Tom Tromey:
https://bugzilla.gnome.org/show_bug.cgi?id=623552#c11

I can see that rawhide is updated, any chance getting new version of glib2 into f20?

[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.

*** Bug 1073284 has been marked as a duplicate of this bug. ***

I just hit this today on a fully updated f20, is this fix coming to f20?

*** Bug 1135789 has been marked as a duplicate of this bug. ***

This is just a cosmetic error, it's not the cause of any problems you're having with gdb.