Re: ptracing a task from core_pattern pipe
From: Daniel Walker
Date: Sat Mar 16 2013 - 20:44:56 EST
On Sat, Mar 16, 2013 at 06:58:45PM +0100, Oleg Nesterov wrote:
> On 03/15, Daniel Walker wrote:
> > I was writing an application to ptrace a process which is dumping core
> > from inside the pipe application for core_pattern.
> This was never possible. And never will, I think.
> > So for example you make core pattern equal to something like
> > "|/bin/corepipe_app" then the kernel runs that app prior to actually
> > killing the process that failed.
> No, the dumper "kills" itself (but see below) and the starts
Not sure what you mean by "dumper" .. The thread that has failed (i.e.
the thread which has seg faulted) is sleeping until the corepipe_app
> > Before the pipe application runs it puts SIGKILL on the pending signal
> > list for the failed application.
> if "it" means the dumper thread then "almost true". It kills other threads
> but not itself.
"it" is in the kernel prior to spawning the corepipe_app , but I think
it's the context of the thread which failed.. The SIGKILL is done in
> (Just in case, this was recently changed. After
> coredump-ensure-that-sigkill-always-kills-the-dumping-thread.patch in -mm
> tree the dumper doesn't run in SIGNAL_GROUP_EXIT, but probably this
> doesn't matter)
> > However the application can't run.
> Which application? Both the dumper and corepipe_app can run...
the "dumper" , assuming I know what you mean, is sleeping.. It can't
run when corepipe_app runs. It wouldn't make sense because the core is
getting saved at that point.
> > This commit,
> > 9899d11f654474d2d54ea52ceaa2a1f4db3abd68
> > seems to put a damper on ptracing the application at this point.
> How can this commit make any difference? It should not.
As I said there is a SIGKILL pending on the "dumper" thread, and your
commit finds the SIGKILL pending.
> > So I wanted to see what you think of all this.. Can we add an exception
> > to this which would allow operations on a task which is dumping core,
> Which ptrace request you think should work at this stage? The coredumping
> task is dying, it can't report, say, signal or syscall. It can report
> nothing except PTRACE_EVENT_EXIT, but only after it closes the pipe.
It can give me it's registers, and allow me access to it's memory space.
That's all I want realistically ..
> > but still has SIGKILL pending. The other way would be to not add SIGKILL
> > till after the pipe app runs.
> See above.
> > As of right now I can PTRACE_ATTACH, but the operations all fail with
> > -ESRCH .
> Sure, because the tracee doesn't (and shouldn't) stop, iow it doesn't
> report any event.
> Could you explain what actually you are trying to do? And what exactly
> doesn't work as you expected?
I'm trying to get the "dumpers" registers and stack out when it fails.
> Now that the coredump is killable (-mm patches), _perhaps_ we can, say,
> add PTRACE_EVENT_CORED_DUMPED reported after binfmt->core_dump(). Not
> sure this is what you need...
Not sure what this would accomplish .. I just want the processes
registers and stack or access to all it's memory.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/