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
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.
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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