From: Oleg Nesterov <oleg@redhat.com>
To: Daniel Walker <dwalker@fifo99.com>
Cc: linux-kernel@vger.kernel.org, Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: ptracing a task from core_pattern pipe
Date: Tue, 19 Mar 2013 21:19:33 +0100 [thread overview]
Message-ID: <20130319201933.GB18670@redhat.com> (raw)
In-Reply-To: <20130318190943.GA16226@fifo99.com>
On 03/18, Daniel Walker wrote:
>
> On Mon, Mar 18, 2013 at 06:03:02PM +0100, Oleg Nesterov wrote:
> >
> > > 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 ?
When the tracee stops in TASK_TRACED for debugger, after that the debugger
can do ptrace(GETREGS/whatever).
> > > 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.
Can't you process the data inplace? You do not need to save it to disk.
I understand, this is probably not very convenient, but any new kernel
feature should be justified. And let me repeat, even if we add
PTRACE_EVENT_COREDUMPED you won't be able to ptrace sub-threads, so
this feature doesn't look very nice.
> > > 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,
Daniel, you can, but:
> since I get ESRCH in
> the corepipe_app for every operation,
This is another thing, and I already explained many times why this happens.
> so that suggests I'd need to attach
> prior to when it crashes.
If you can attach prior to when it crashes then I do not understand why
do you need the piped coredump at all. You can do everything you need
after the tracee reports SEGFAULT or another sig_kernel_coredump() signal.
> > 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 ?
Well, yes... But I am not sure I understand the question...
What this "but continue running" means? Of course corepipe_app can run
after it closes the pipe.
Daniel, I feel you misunderstand something (or perhaps it is me), but
I can't understand what exactly you do not understand, sorry ;) I will
be happy to help if you ask the more "explicit" questions.
Oleg.
next prev parent reply other threads:[~2013-03-19 20:21 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 [this message]
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=20130319201933.GB18670@redhat.com \
--to=oleg@redhat.com \
--cc=dvlasenk@redhat.com \
--cc=dwalker@fifo99.com \
--cc=linux-kernel@vger.kernel.org \
/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.