Bug 525721

Created attachment 362662 [details]
Proposed ABRT fix.

Description of problem:
There were complaints (from mcepl) ABRT sometimes produces bogus backtraces.

This can happen in the common case of running program being older version than its on-disk files already upgraded by YUM while it was running.

There are two problems:
* ABRT calls GDB with explicit `file' command and thus incorrectly overriding
  its automatic lookup of matching executable binary (this Bug).
* GDB could load a library matching just by its name, not by its build-id
  stored in the core file (fixed now for GDB in Rawhide as Bug 524572).

Version-Release number of selected component (if applicable):
abrt-0.0.9-2.fc12

How reproducible:
just checked the sources

Steps to Reproduce:
wget http://kojipkgs.fedoraproject.org/packages/coreutils/7.6/{4,5}.fc12/x86_64/coreutils-{,libs-,debuginfo-}7.6-{4,5}.fc12.x86_64.rpm
rm -f core.*; rpm -U --oldpackage *7.6-4*; (ulimit -c unlimited; sleep 1h& p=$!; sleep 1; rpm -U *7.6-5*; kill -SEGV $p)

Actual results:
echo CURRENT:; gdb -q -ex bt -ex q sleep ./core.*
CURRENT:
Reading symbols from /bin/sleep...Reading symbols from /usr/lib/debug/bin/sleep.debug...done.
done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib64/librt-2.10.90.so...Reading symbols from /usr/lib/debug/lib64/librt-2.10.90.so.debug...done.
done.
Loaded symbols for /lib64/librt-2.10.90.so
Reading symbols from /lib64/libc-2.10.90.so...Reading symbols from /usr/lib/debug/lib64/libc-2.10.90.so.debug...done.
done.
Loaded symbols for /lib64/libc-2.10.90.so
Reading symbols from /lib64/libpthread-2.10.90.so...Reading symbols from /usr/lib/debug/lib64/libpthread-2.10.90.so.debug...done.
done.
Loaded symbols for /lib64/libpthread-2.10.90.so
Reading symbols from /lib64/ld-2.10.90.so...Reading symbols from /usr/lib/debug/lib64/ld-2.10.90.so.debug...done.
done.
Loaded symbols for /lib64/ld-2.10.90.so
Core was generated by `sleep 1h'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000038500a7380 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
#0  0x00000038500a7380 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0x0000000000403d9b in rpl_nanosleep (requested_delay=0x7fff3813c8c0, remaining_delay=0x0) at nanosleep.c:69
#2  0x000000000040343b in xnanosleep (seconds=<value optimized out>) at xnanosleep.c:112
#3  0x00000000004016fc in main (argc=2, argv=<value optimized out>) at sleep.c:147
Current language:  auto
The current source language is "auto; currently asm".


Expected results:
echo REQUESTED:; gdb -q -ex bt -ex q -c ./core.*
REQUESTED:
Missing separate debuginfo for the main executable file
Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/06/b0a4f8365ef2efae035d4f83eb44befb60d543
Core was generated by `sleep 1h'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000038500a7380 in ?? ()
#0  0x00000038500a7380 in ?? ()
#1  0x0000000000403d9b in ?? ()
#2  0x0010000000000000 in ?? ()
#3  0x000000384fc14bc5 in ?? ()
#4  0x000000000006bae8 in ?? ()
#5  0x0000000031090c07 in ?? ()
#6  0x0000000000000e10 in ?? ()
#7  0x0000000000000000 in ?? ()


Additional info:
In this case the "Actual results" dump is in fact correct as the differences between coreutils-7.6-{4,5}.fc12.x86_64 are not visible in this case.
But in general case the "Actual results" dump can be completely bogus.

This difference in the patch sure currently has no effect:
-        fTmp << "core " << pDebugDumpDir << "/"FILENAME_COREDUMP"\n";
+        fTmp << "core-file " << pDebugDumpDir << "/"FILENAME_COREDUMP"\n";
but one should not rely on the shortened command names as sometimes they change.