Messages in this thread | | | Date | Mon, 12 Mar 2012 19:58:31 +0100 | From | Denys Vlasenko <> | Subject | Re: Extending coredump note section to contain filenames |
| |
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
| |