Re: Extending coredump note section to contain filenames

[Denys Vlasenko <dvlasenk@redhat.com>]

On 03/12/2012 05:53 PM, Jan Kratochvil wrote:
> On Mon, 12 Mar 2012 13:05:56 +0100, Denys Vlasenko wrote:
>> Why we don't save library names in coredump?
>
> Because they are useless.

They may be useless in some situations. Not in every situation,
by a long shot. Here is a live example from my system:

$ ulimit -c unlimited
$ md5sum </dev/zero &
$ pid=$!
$ sleep 1
$ kill -ABRT $pid
$ gdb -ex "core core.12977"
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
...
Missing separate debuginfo for the main executable file
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ec/1fd70dbee0db36eff9527254d9d2bbfd260f13
[New LWP 12977]
Core was generated by `md5sum'.
Program terminated with signal 6, Aborted.
#0  0x0804b2b0 in ?? ()
(gdb) bt
#0  0x0804b2b0 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

      No backtrace at all.
      Let's tell it which binary was that:

(gdb) file /usr/bin/md5sum
Reading symbols from /usr/bin/md5sum...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install coreutils-8.12-6.fc16.i686
(gdb) bt
#0  0x0804b2b0 in ?? ()
#1  0x0804bdd8 in ?? ()
#2  0x0804a093 in ?? ()
#3  0x08049659 in ?? ()
#4  0xb760f6b3 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

      This is better, isn't it?
      Wouldn't it be nice if gdb would retrieve binary's name by itself?
      (BTW: nothing prevents it from checking build ids and refusing
      to use it if they don't match.)

> If you have a filename there how to find which
> content it should match?  Even if you verify the file is still there with the
> same content there is a race it can no longer be true when you read the core
> file 5 seconds later.

And maybe root will run "rm -rf /*" in parallel. By this logic,
we should just give up on using computers.


> The build-id mapping server above always works and without races.

But it is not always available. Some people don't want to be connected
to internet; other can't be connected.


>>> it can have unknown content etc.
>>
>> I don't understand. *What* can have unknown content?
>
> You will save there "/lib64/libc-2.14.90.so".  But the next day you have no
> idea which compilation or build the core file was generated for, that virtual
> machine can be either already updated or even reinstalled from scratch etc.
> "/lib64/libc-2.14.90.so" does not say anything about the build.

Does it follow from the above that filenames are *never* useful?
I don't think so.

-- 
vda