All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@fifo99.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ptracing a task from core_pattern pipe
Date: Mon, 18 Mar 2013 12:09:44 -0700	[thread overview]
Message-ID: <20130318190943.GA16226@fifo99.com> (raw)
In-Reply-To: <20130318170302.GA21248@redhat.com>

On Mon, Mar 18, 2013 at 06:03:02PM +0100, Oleg Nesterov wrote:
> > Assume that's not happening, why would ptrace give me -ESRCH, yet
> > /proc/<pid>/status would show me ptrace attached to the thread.
> 
> And why do you think this should be explained by SIGKILL?

It's an assumption, if I knew before you would be getting a patch
instead of an email.

> > > Please explain what difference this patch makes in your testing.
> >
> > I haven't tested with or with out it, I've just read the code and it
> > seems to be the only way I'm getting ESRCH back from ptrace.. 
> 
> No,
> 
> > For instance, I ptrace attach from inside the corepipe_app then try
> > PTRACE_GETREGS and you get -ESRCH .
> 
> Sure. PTRACE_GETREGS and (almost) any other request can only succeed
> if the tracee is TASK_TRACED! I already told you that ptrace() doesn't
> and can't work exactly because the dumper never does ptrace_stop().

When does ptrace_stop run ?

> > > > It can give me it's registers, and allow me access to it's memory space.
> > > > That's all I want realistically ..
> > >
> > > ...
> > >
> > > > I'm trying to get the "dumpers" registers and stack out when it fails.
> > >
> > > Can't you read the generated core for that? And see below...
> >
> > I'm not sure if it would accomplish what I need. I can't save the whole core,
> > and I can't get memory to save large chunks of it.
> 
> Not sure I understand this part...

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.

> >
> > Oh, I think I see what you mean. I would ptrace attach prior to the
> > thread crashing ,
> 
> I don't understand what "prior to the thread crashing" means... the pipe
> hanlder is spawned after the task has already initiated the coredump...
> IOW, other threads are already killed and we are ready to actually dump
> the core.

I can't attach to the thread after it's crashed, since I get ESRCH in
the corepipe_app for every operation, so that suggests I'd need to attach
prior to when it crashes.

> > and get an event for when it crashes ?
> 
> And get an event after coredump_app closes the pipe. Assuming that
> you use PTRACE_SEIZE(PTRACE_O_CORE_DUMPED) rather that PTRACE_ATTACH.
> And assuming you do this before you close the pipe, otherwise it can
> exit before you do PTRACE_SEIZE.

So corepipe_app would PTRACE_SEIZE then close the pipe but continue running ?

> > > Of course, this can't help to ptrace/inspect other threads, they are
> > > already (well, almost) dead at this point.
> >
> > Ideally I would want to attach after it crashes, cause other wise I'd
> > have to ptrace attach to a lot of threads (to monitor the whole system).
> 
> See above. You do not need to attach in advance.
> 
> But once again, you can't attach the sub-threads, they are already dead
> when coredump_app is called. PTRACE_ATTACH will work but this can help,
> a sub-thread will never report any event and PF_EXITING is already set.

Ok ..

Daniel


  reply	other threads:[~2013-03-18 19:09 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 [this message]
2013-03-19 20:19             ` Oleg Nesterov
2013-03-25  9:48               ` Denys Vlasenko
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=20130318190943.GA16226@fifo99.com \
    --to=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.