All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Vlasenko <dvlasenk@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Daniel Walker <dwalker@fifo99.com>, linux-kernel@vger.kernel.org
Subject: Re: ptracing a task from core_pattern pipe
Date: Mon, 25 Mar 2013 10:48:07 +0100	[thread overview]
Message-ID: <51501D57.1000605@redhat.com> (raw)
In-Reply-To: <20130319201933.GB18670@redhat.com>

On 03/19/2013 09:19 PM, Oleg Nesterov wrote:
>> The above is regarding the situation which I'm running my corepipe_app ,
>> i.e. my system doesn't have a disk to save a core file for parsing.
> 
> Can't you process the data inplace? You do not need to save it to disk.

Daniel said:

>> I'm trying to get the "dumpers" registers and stack out when it fails.

Registers would be easy'ish to get from coredump:
they are contained in note sections which are at the beginning
of the coredump. You can implement necessary parsing without
too much pain.

Getting at stack would be harder.

But by asking kernel to allow you to poke around dead task's
address space with ptrace() calls you just shift difficulty away from you
(today you need to implement in-memory ELF parsing) to kernel people
(they will need to implement *and support* ptracing of coredumping
tasks).

This is somewhat unfair, considering that coredumping code in kernel
is already a source of many complications, and that kernel-side coding
is harder than userspace.

I think you are lucky that ptrace attach even *works* on coredumping task.
No documentation ever guaranteed such a thing.

Did you try whether process_vm_readv() works on coredumping task?
If it is, then you can get at dying process' address space that way.


-- 
vda

  reply	other threads:[~2013-03-25  9:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-16  1:15 ptracing a task from core_pattern pipe Daniel Walker
2013-03-16 17:58 ` Oleg Nesterov
2013-03-17  0:44   ` Daniel Walker
2013-03-17 14:34     ` Oleg Nesterov
2013-03-17 21:11       ` Daniel Walker
2013-03-18 17:03         ` Oleg Nesterov
2013-03-18 19:09           ` Daniel Walker
2013-03-19 20:19             ` Oleg Nesterov
2013-03-25  9:48               ` Denys Vlasenko [this message]
2013-03-27  3:26                 ` Daniel Walker
2013-03-27 12:17                   ` 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=51501D57.1000605@redhat.com \
    --to=dvlasenk@redhat.com \
    --cc=dwalker@fifo99.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.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.