Bug 573050 - RFE: add "rpm -qf" data whenever displaying location information in gdb
Summary: RFE: add "rpm -qf" data whenever displaying location information in gdb
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Sergio Durigan Junior
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-12 17:31 UTC by Dave Malcolm
Modified: 2019-10-28 15:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-28 13:51:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Malcolm 2010-03-12 17:31:01 UTC
Description of problem:
I am constantly dealing with backtraces, generally from ABRT, and often involving components that I'm not familiar with (I maintain python, and so any bug in an extension module can potentially cause a crash that ends up in the python bug queue).

gdb backtraces contain two types of location information:
(i) "at" a source file.  
(ii) "from" an ELF file.

see e.g. attachment 376278 [details] to bug 544519.
At frame 0, I see an example of (i):
#0  visit_decref (op=0x7f4a9ebd7300, data=0x0) at Modules/gcmodule.c:271

At frame 14, I see an example of (ii):
#14 0x00007f4a873820ef in ?? ()
   from /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so


My request is: can the Fedora build of gdb please contain an extension (probably in python) that adds rpm-level information to these frames.


For example, frame 0 might read better as:
#0  visit_decref (op=0x7f4a9ebd7300, data=0x0) at Modules/gcmodule.c:271 (python-debuginfo-2.6.2-2.fc12.x86_64)

i.e. with a trailing "rpm -qf" of the source file

Similarly frame 14 might read better as:
#14 0x00007f4a873820ef in ?? ()
   from /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so (pygobject2-2.20.0-1.fc12.x86_64)

i.e. with a trailing "rpm -qf" of the ELF file

Note that I'm guessing at the versions here: I'd love to know what NVR the reporter of the bug actually had installed, and embedding it here would show at every level of the callstack the version of the software that we're are actually dealing with.

I believe this would greatly enhance the value of ABRT-generated backtraces.

Case (i) might be better handled if instead of displaying just the source file, it also displayed both the ELF file and the "rpm -qf" of that ELF file, if that's possible.


If a file is not managed in rpm I'd want no output.


Since "rpm -qf" is non-trivial, it may be best to hand-filter things, so that it only queries for source files that are below /usr/src/debug, and for ELF files that are in /usr/bin or in /usr/lib|/usr/lib64 (details unclear).

Is this implementable with the current gdb python extensions, or on the roadmap?  Thanks!

The same output could presumably be shown whenever gdb is displaying a location e.g. when the user issues the  "up" and "down" commands

Version-Release number of selected component (if applicable):
gdb-7.0.1-26.fc12.i686

Comment 1 Jan Kratochvil 2010-03-12 17:57:07 UTC
I would like to divide this request into two, Fedora dependent and upstream:

(1) upstream: Could you please post it to <gdb>?

I would like longterm there something like:
(In reply to comment #0)
> #0  visit_decref (op=0x7f4a9ebd7300, data=0x0) at Modules/gcmodule.c:271

#0  visit_decref (op=0x7f4a9ebd7300, data=0x0) at Modules/gcmodule.c:271 from libpython2.6.so


> At frame 14, I see an example of (ii):
> #14 0x00007f4a873820ef in ?? ()
>    from /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so

#14 0x00007f4a873820ef in ?? () from _gobject.so


> For example, frame 0 might read better as:
> #0  visit_decref (op=0x7f4a9ebd7300, data=0x0) at Modules/gcmodule.c:271
> (python-debuginfo-2.6.2-2.fc12.x86_64)

I do not understand here how the rpm name is better than libpython2.6.so?
(For different versions of a specific library see below.)


> Note that I'm guessing at the versions here: I'd love to know what NVR the
> reporter of the bug actually had installed, and embedding it here would show
> at every level of the callstack the version of the software that we're are
> actually dealing with.

This is not a problem of GDB.  It is a problem of Fedora release engineering and GDB should not be used to substitute flaws in Fedora distribution.

http://lists.fedoraproject.org/pipermail/devel/2010-January/129401.html

`rpm -qf' can be misleading due to possibly (a) binaries overwritten by some custom "make install", (b) on-disk libraries upgraded while older ones still running etc.  build-id already present in the core file is the safe way to identify the unique binary.

Mapping build-id <-> NVRA is a nice issue but completely offtopic for GDB, this request should come from ABRT.

Comment 2 Bug Zapper 2010-11-03 19:59:33 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Fedora Admin XMLRPC Client 2011-01-06 03:21:39 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Dave Malcolm 2019-10-28 13:51:32 UTC
These days, if I try debugging a process that contains code without debuginfo, gdb now provides a very useful prompt as to what I need to type to get the correct debuginfo:

e.g.:

$ gdb ls
GNU gdb (GDB) Fedora 8.3-6.fc30
[...snip...]
Reading symbols from ls...
(No debugging symbols found in ls)
Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.31-2.fc30.x86_64

This basically fixes the issue I was reporting back in 2010; thanks for implementing it.

Closing this out as WORKSFORME.

Comment 5 Jan Kratochvil 2019-10-28 15:45:06 UTC
This "debuginfo-install" suggestion functionality is in Fedora GDB since January 2018 so it should have been there during Comment 0:
https://src.fedoraproject.org/rpms/gdb/c/6a80c39af8f12a670c2dc194674a246fe1ded687


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