All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Vlasenko <dvlasenk@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>,
	linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>
Subject: Re: Extending coredump note section to contain filenames
Date: Mon, 12 Mar 2012 13:05:56 +0100	[thread overview]
Message-ID: <4F5DE6A4.2030303@redhat.com> (raw)
In-Reply-To: <20120309172934.GA18173@host2.jankratochvil.net>

On 03/09/2012 06:29 PM, Jan Kratochvil wrote:
> On Fri, 09 Mar 2012 18:13:49 +0100, Denys Vlasenko wrote:
>> gdb retrieves loaded library names by examining dynamic loader's
>> data stored in the coredump's data segments. It uses intimate
>> knowledge how and where dynamic loader keeps the list of loaded
>> libraries.
>
> this is the backward compatible way and it is no longer the right one with
> build-ids.
 >
 > GDB should scan the address space for mapped build-ids and map symbol files
 > accordingly.

Build-ids are useful, but they still don't map directly to the names
of loaded files. You need to rely on /usr/lib/debug/.build-id/XX/YYYYYYYYYY
symlinks to translate build-ids to names.

For example, on my home machine (linux-from-scratch style) I don't have
/usr/lib/debug/.build-id/* directory at all. So build-ids can't be used
to find the binary and libraries there.

Why we don't save library names in coredump? I see no logical reason
not to do so. Even if those names sometimes won't be reliable
("deleted files" problem), it's not a good reason to shoot ourself
in the food and deprive ourself from this information 100% of the time.


>> Another question is detection of deleted files.
>> If /usr/lib/xulrunner-2/libmozjs.so was updated while program ran
>> and now file mapped into process address space does not correspond
>> to the same-named file on disk, can we help users to detect this? How?
>> By saving maj/min/inode? Hash thereof?
>> File size?
>> File's md5sum (probably not, way too expensive. But nicely robust...)?
>
> build-id is already being saved.  This is all that matters.  Filename does not
> say anything - as you noticed it can be even already deleted,

Yes, the file can be deleted/updated-via-rename. That's the case
I want to be possible to detect.

> it can have unknown content etc.

I don't understand. *What* can have unknown content?

 > I do not see what problems you target here.

I'm thinking whether we should supply some mechanism for detecting
"deleted/updated file" problem. Even if this would be a heuristic.
I'll be satisfied with 99.9999% success rate instead of 100% :)

-- 
vda

  reply	other threads:[~2012-03-12 12:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-09 17:13 Extending coredump note section to contain filenames Denys Vlasenko
2012-03-09 17:29 ` Jan Kratochvil
2012-03-12 12:05   ` Denys Vlasenko [this message]
2012-03-12 12:13     ` Denys Vlasenko
2012-03-12 16:53     ` Jan Kratochvil
2012-03-12 18:58       ` Denys Vlasenko
2012-03-12 19:08         ` Jan Kratochvil
2012-03-12 19:45           ` Denys Vlasenko
2012-03-12 22:07             ` Jan Kratochvil
2012-03-12 22:16             ` Jan Kratochvil
2012-03-13 12:12         ` Denys Vlasenko
2012-03-13 12:19           ` Jan Kratochvil
2012-03-12 22:21       ` H. Peter Anvin
2012-03-12 22:31         ` Jan Kratochvil
2012-03-13  0:16           ` H. Peter Anvin
2012-03-13  0:27             ` Jan Kratochvil
2012-03-13  0:31               ` H. Peter Anvin
2012-03-13  0:36                 ` Jan Kratochvil
2012-03-13  0:42                   ` H. Peter Anvin
2012-03-13  0:46                     ` Jan Kratochvil
2012-03-13  0:50                       ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F5DE6A4.2030303@redhat.com \
    --to=dvlasenk@redhat.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@hack.frob.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.