Hi,
Cced to crash-catcher@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
^^^^->core-file
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 q
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 ignored.
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.
example: # 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".
ABRT should 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 use 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.
Thanks, Jan