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:
> file BINARY
> code COREFILE
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 find the
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 /usr/lib/debug/.build-id/00/5af5b5e7d6ab560825b0747fcbe41112431b8c.debug -> ../../usr/bin/makestrs.debug
> 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
0x3979600000+0x36e000 ec8dd400904ddfcac8b1c343263a790f977159dc@0x3979600280 /lib64/libc-2.10.1.so /usr/lib/debug/lib64/libc-2.10.1.so.debug libc.so.6
yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ec/8dd400904ddfcac8b1c343263a790f977159dc.debug
(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.
This is a first step in a report plugin that is intended to report
directly to Red Hat support, with all the Red Hat specific stuff
stripped out (or actually pushed into the config file).
It works by FTPing a tar'ed compressed encripted file to an anonymous
FTP site, and then sending a 'receipt' (containing the filename, md5sum,
and encryption key) of that upload to an actual ticket in a ticketing
system. This version doesn't yet send the receipt.