From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756511Ab2CLS6f (ORCPT <rfc822;w@1wt.eu>);
	Mon, 12 Mar 2012 14:58:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:19379 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756242Ab2CLS6d (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 12 Mar 2012 14:58:33 -0400
Message-ID: <4F5E4757.705@redhat.com>
Date: Mon, 12 Mar 2012 19:58:31 +0100
From: Denys Vlasenko <dvlasenk@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Jan Kratochvil <jan.kratochvil@redhat.com>
CC: Roland McGrath <roland@hack.frob.com>, linux-kernel@vger.kernel.org,
        Oleg Nesterov <oleg@redhat.com>, Kushal Das <kdas@redhat.com>
Subject: Re: Extending coredump note section to contain filenames
References: <4F5A3A4D.1020008@redhat.com> <20120309172934.GA18173@host2.jankratochvil.net> <4F5DE6A4.2030303@redhat.com> <20120312165359.GA32400@host2.jankratochvil.net>
In-Reply-To: <20120312165359.GA32400@host2.jankratochvil.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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