Cced to <crash-catcher(a)lists.fedorahosted.org>.
On Wed, 26 Aug 2009 04:31:12 +0200, Denys Vlasenko wrote:
When we process a crash, we have a core file. We just run gdb on it
in batch mode by running
gdb -batch -x FILE
where FILE contains:
Fedora GDB does not need the first "file" command, it will find out the binary
by its build-id. But for binaries either without build-id (=built on
non-Fedora GCC) or which do not have their debuginfo rpm installed we would
not find the filename of BINARY so it is right to say also "file BINARY".
thread apply all backtrace full
It tries to locate debuginfo by finding executable's build id,
[Jan, can you expand on this - does gdb look at executable
or at the core file in order to find build id? If it looks at core file
for this, does code file contain build ids of loaded libraries too?]
then looks it up in /usr/lib/debug/.build-id/XX/XXXXXXXXXXXXXXX
and uses if it is found.
If you type "file BINARY" it will try to find the separate .debug file
according to the build-id of BINARY. In such case COREFILE build-id would be
If you type just "core-file COREFILE" (without "file BINARY") it will
binary according to its build-id.
Libraries are always found preferred to their build-id.
Separate debug info files for binaries and libraries are always found
preferred according to the build-id in the binary/library (not core file).
But as build-id of the binary, .debug file and the core file note must be
always the same by definition this paragraph is just an implementation detail.
# ls -l /usr/lib/debug/.build-id/00/5af5b5e7d6ab560825b0747fcbe41112431b8c.debug
lrwxrwxrwx 1 root root 28 2009-07-20 18:08
However, we (abrt) do not know whether debuginfo is installed,
so currently we just run "debuginfo-install -y -- PACKAGE".
eu-unstrip -n --core=/tmp/core.20546
and for its each produced line like
/lib64/libc-2.10.1.so /usr/lib/debug/lib64/libc-2.10.1.so.debug libc.so.6
yum --enablerepo='*-debuginfo' install
(or some other yum/gpk command what recommend their maintainers)
This is a simple approach, but it has several drawbacks.
Yes, I was already suggesting the direct build-id way before which avoids the
package versions mistakes and it may even work one day after we convince
releng they should keep debuginfos even for some (all) previous versions of
packages. Currently for any longterm running programs/daemons the crash
backtrace always fails as there is no longer the debuginfo available for the
running version of the program (while the on-disk program binary is already
updated, incl. its debuginfo package, even if it was already installed).
So, Jan, what is this pk-debuginfo-install thing, and how it can
help us here?
Tried installing pk-debuginfo-install but it wanted to install some graphical
mess. Crashes bugreporting must not rely on graphical tools to be usable on
the RHEL text-only server farms.