Hi,
I was writing an application to ptrace a process which is dumping core
from inside the pipe application for core_pattern.
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.
Before the pipe application runs it puts SIGKILL on the pending signal
list for the failed application. However the application can't run.
This commit,
9899d11f654474d2d54ea52ceaa2a1f4db3abd68
seems to put a damper on ptracing the application at this point.
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,
but still has SIGKILL pending. The other way would be to not add SIGKILL
till after the pipe app runs.
As of right now I can PTRACE_ATTACH, but the operations all fail with
-ESRCH .
Daniel
Hi Daniel,
Sorry, I can't understand your email...
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
/bin/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.
(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...
> 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.
> 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.
> 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?
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...
Oleg.
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
> /bin/corepipe_app.
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
returns.
> > 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.
Daniel
On 03/16, Daniel Walker wrote:
>
> 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
> > /bin/corepipe_app.
>
>
> Not sure what you mean by "dumper" .. The thread that has failed (i.e.
> the thread which has seg faulted)
Yes, and this is the thread which spawns corepipe_app and dumps the core.
> is sleeping until the corepipe_app
> returns.
Yes, but it dumps the core first. And to clarify, it sleeps until
corepipe_app closes the pipe.
> > > 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
Can't understand... Yes it kills other threads before it starts the
corepipe_app. To clarify, "kills" means it sends SIGKILL to other threads
and wait until they all park in exit_mm().
> > (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 sleeps only after it dumps the core. It only sleeps to ensure we
do not close the write side prematurely.
> It can't
> run when corepipe_app runs. It wouldn't make sense because the core is
> getting saved at that point.
At this point it doesn't run, yes. But while it dumps the core they
both run in parallel.
> > > 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,
As I said, there is no SIGKILL pending on the "dumper" thread. (unless it
is actually killed of course).
> and your
> commit finds the SIGKILL pending.
Can't understand. It can find the pending SIGKILL, but only after ptrace()
returns sucessfully and the tracee was stopped. And the dumper never stops.
Please explain what difference this patch makes in your testing.
> > > 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 ..
...
> 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...
> > 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.
Confused... why do you think PTRACE_EVENT_CORE_DUMPED reported after
binfmt->core_dump() won't allow to do this?
Of course, this can't help to ptrace/inspect other threads, they are
already (well, almost) dead at this point.
Oleg.
On Sun, Mar 17, 2013 at 03:34:46PM +0100, Oleg Nesterov wrote:
> > > (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 sleeps only after it dumps the core. It only sleeps to ensure we
> do not close the write side prematurely.
The dumper thread is sleeping when the corepipe_app runs .. I ran "cat
/proc/<pid>/status" from the corepipe_app .. It shows the dumper as sleeping.
> > It can't
> > run when corepipe_app runs. It wouldn't make sense because the core is
> > getting saved at that point.
>
> At this point it doesn't run, yes. But while it dumps the core they
> both run in parallel.
Not following you here.. If it's sleeping how can it be running too ?
> > > > 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,
>
> As I said, there is no SIGKILL pending on the "dumper" thread. (unless it
> is actually killed of course).
I pretty sure do_coredump()->core_wait()->zap_threads()->zap_process()
adds SIGKILL.. Assume that's not happening, why would ptrace give me -ESRCH, yet
/proc/<pid>/status would show me ptrace attached to the thread.
> > and your
> > commit finds the SIGKILL pending.
>
> Can't understand. It can find the pending SIGKILL, but only after ptrace()
> returns sucessfully and the tracee was stopped. And the dumper never stops.
>
> 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..
For instance, I ptrace attach from inside the corepipe_app then try
PTRACE_GETREGS and you get -ESRCH .
> > > > 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 ..
>
> ...
>
> > 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.
ptrace after it crashes seems like a nice solution cause I can just
examine the process already in memory.
> > > 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.
>
> Confused... why do you think PTRACE_EVENT_CORE_DUMPED reported after
> binfmt->core_dump() won't allow to do this?
Oh, I think I see what you mean. I would ptrace attach prior to the
thread crashing , and get an event for when it crashes ?
> 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).
Daniel
On 03/17, Daniel Walker wrote:
>
> On Sun, Mar 17, 2013 at 03:34:46PM +0100, Oleg Nesterov wrote:
> >
> > It sleeps only after it dumps the core. It only sleeps to ensure we
> > do not close the write side prematurely.
>
> The dumper thread is sleeping when the corepipe_app runs .. I ran "cat
> /proc/<pid>/status" from the corepipe_app .. It shows the dumper as sleeping.
It runs whatever you see in /proc/status ;) Who do you think dumps the
core? The dumper thread itself. But see below.
> > > It can't
> > > run when corepipe_app runs. It wouldn't make sense because the core is
> > > getting saved at that point.
> >
> > At this point it doesn't run, yes. But while it dumps the core they
> > both run in parallel.
>
> Not following you here.. If it's sleeping how can it be running too ?
See above. Once again, it dumps the core _then_ sleeps waiting pipe
handler which should close the pipe.
And of course, you can see it sleeping in, say, pipe_write() if
the buffer is full and the pipe handler doesn't read the data.
> > > As I said there is a SIGKILL pending on the "dumper" thread,
> >
> > As I said, there is no SIGKILL pending on the "dumper" thread. (unless it
> > is actually killed of course).
>
> I pretty sure do_coredump()->core_wait()->zap_threads()->zap_process()
> adds SIGKILL..
static int zap_process(struct task_struct *start, int exit_code)
{
...
do {
task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
------------> if (t != current && t->mm) {
sigaddset(&t->pending.signal, SIGKILL);
signal_wake_up(t, 1);
nr++;
}
} while_each_thread(start, t);
}
> 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?
> > 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().
> > > 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...
> ptrace after it crashes seems like a nice solution cause I can just
> examine the process already in memory.
OK.
> > > > 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.
> >
> > Confused... why do you think PTRACE_EVENT_CORE_DUMPED reported after
> > binfmt->core_dump() won't allow to do this?
>
> 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.
> 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.
> > 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.
Oleg.
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
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.
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
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
On 03/27/2013 04:26 AM, Daniel Walker wrote:
> 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..
As I see it, dumping task is past the point where it can enter
ptrace-stops.
It's like asking to ptrace a task which already entered the kernel
via exit(0) syscall and complaining that "it doesn't work".
Of course it does not: a ptrace-stop can happen only after syscall
returns to userspace, and exit() doesn't return.
Coredumping is similar: the task is in kernelspace and
it won't ever return to userspace.
--
vda