All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@fifo99.com>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: ptracing a task from core_pattern pipe
Date: Tue, 26 Mar 2013 20:26:54 -0700	[thread overview]
Message-ID: <20130327031737.GA12602@fifo99.com> (raw)
In-Reply-To: <51501D57.1000605@redhat.com>

On Mon, Mar 25, 2013 at 10:48:07AM +0100, Denys Vlasenko wrote:
> 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.

There exists /proc/<pid>/mem and /proc/<pid>/maps on these tasks. If
those don't work then that's a straight up defect..

> 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.

There not much different from userspace between a task running, and one
dumping.. I think it should be the inverse, ptrace either needs to work
or the special case needs to be documented that it doesn't work.

However, I do agree that you can parse the core file..

Daniel

  reply	other threads:[~2013-03-27  3:26 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
2013-03-27  3:26                 ` Daniel Walker [this message]
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=20130327031737.GA12602@fifo99.com \
    --to=dwalker@fifo99.com \
    --cc=dvlasenk@redhat.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.