From: Tim Bird <tim.bird@am.sony.com>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Andi Kleen <andi@firstfloor.org>, Oleg Nesterov <oleg@redhat.com>,
linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Questions about ptrace on a dying process
Date: Thu, 1 Mar 2012 10:18:13 -0800 [thread overview]
Message-ID: <4F4FBD65.7020006@am.sony.com> (raw)
In-Reply-To: <201203010812.54769.vda.linux@googlemail.com>
On 02/29/2012 11:12 PM, Denys Vlasenko wrote:
> On Wednesday 29 February 2012 21:45, Tim Bird wrote:
>> This is on embedded systems, where the dump is not saved. The dump
>> is available via stdin to the core pipe handler, but it would be
>> kind of a pain to wrapper that for random access, which is needed
>> for stuff like stack unwinding.
>
> Stack unwinding only requires the stack data and knowledge
> of the mapped binary and library files. You can parse coredump's ELF header,
> and skip all sizable data segments which you won't need anyway.
>
> I estimate that usually you will need to save only ~150k of data
> in order to produce a stacktrace, and even then,
> only because Linux pre-allocates ridiculously large
> stack for every new process - 132k. It can easily be reduced
> to something saner with one-line patch.
My budget for each crash report is about 8k. I have to do
the unwind at the time of the crash (on target) (and without
symbols - these are added later on a host). Given the other
stuff I want to save, saving the whole stack is usually not
an option, and saving a coredump is out of the question.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
next prev parent reply other threads:[~2012-03-01 18:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 18:06 Questions about ptrace on a dying process Tim Bird
2012-02-29 18:50 ` Oleg Nesterov
2012-02-29 20:53 ` Tim Bird
2012-02-29 19:12 ` Andi Kleen
2012-02-29 20:45 ` Tim Bird
2012-03-01 7:12 ` Denys Vlasenko
2012-03-01 18:18 ` Tim Bird [this message]
2012-03-02 1:29 ` Denys Vlasenko
2012-03-01 18:30 ` Tim Bird
2012-03-01 19:02 ` Denys Vlasenko
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=4F4FBD65.7020006@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=vda.linux@googlemail.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.