* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
[not found] <20061011195727.26918.qmail@sourceware.org>
@ 2006-10-11 20:13 ` Mark Wielaard
2006-10-11 20:57 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Mark Wielaard @ 2006-10-11 20:13 UTC (permalink / raw)
To: frysk; +Cc: npremji
Hi Nurdin,
On Wed, 2006-10-11 at 19:57 +0000, npremji@sourceware.org wrote:
> frysk-core/frysk/proc
> * LinuxTask.java (sendAttach): Manually tell the thread that the process
> has been attached Fixes 3316.
Could you explain this a bit?
As far as I can see this change makes it so that a SIGCHLD is send to
the Thread calling sendAttach(). Why do we want to do that? Is that
Thread special. And if so, how does it react to a SIGCHLD?
BTW. You seem to use a different method of indentation then is customary
in the rest of that file.
Cheers,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
2006-10-11 20:13 ` frysk-core/frysk/proc LinuxTask.java TestProcS Mark Wielaard
@ 2006-10-11 20:57 ` Andrew Cagney
2006-10-11 21:26 ` Mark Wielaard
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2006-10-11 20:57 UTC (permalink / raw)
To: Mark Wielaard; +Cc: frysk, npremji
Mark Wielaard wrote:
> Hi Nurdin,
>
> On Wed, 2006-10-11 at 19:57 +0000, npremji@sourceware.org wrote:
>
>> frysk-core/frysk/proc
>> * LinuxTask.java (sendAttach): Manually tell the thread that the process
>> has been attached Fixes 3316.
>>
>
> Could you explain this a bit?
>
Kernel "feature", do I need to go on? ;-)
Nurden, I would greatly expand the comment though, make it more blunt,
and prefix with XXX so we know its bad; and reference the frysk bug
number; and post it here :-)
> As far as I can see this change makes it so that a SIGCHLD is send to
> the Thread calling sendAttach(). Why do we want to do that? Is that
> Thread special. And if so, how does it react to a SIGCHLD?
>
> BTW. You seem to use a different method of indentation then is customary
> in the rest of that file.
>
>
Likely eclipse vs emacs again - emacs thinks Java indentation is 4
characters, eclipse I'm not sure. Fixed if someone re-indents the file.
Andrew
PS: Kernel doesn't send frysk a SIGCHLD, notifying of the presence of
waitpid event, when attaching to a suspended process.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
2006-10-11 20:57 ` Andrew Cagney
@ 2006-10-11 21:26 ` Mark Wielaard
2006-10-11 21:39 ` Nurdin Premji
2006-10-11 22:33 ` Andrew Cagney
0 siblings, 2 replies; 6+ messages in thread
From: Mark Wielaard @ 2006-10-11 21:26 UTC (permalink / raw)
To: Andrew Cagney; +Cc: frysk, npremji
Hi Andrew,
On Wed, 2006-10-11 at 16:57 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > On Wed, 2006-10-11 at 19:57 +0000, npremji@sourceware.org wrote:
> >
> >> frysk-core/frysk/proc
> >> * LinuxTask.java (sendAttach): Manually tell the thread that the process
> >> has been attached Fixes 3316.
> >
> > Could you explain this a bit?
> >
> Kernel "feature", do I need to go on? ;-)
I was afraid of that... I suspect that since the task is already
suspended no SIGSTOP is send after we ptrace attach to it, so we never
notice actually attaching to it. And because it is suspended, we cannot
send it a continue since it shouldn't continue till it is woken up for
real.
> Nurden, I would greatly expand the comment though, make it more blunt,
> and prefix with XXX so we know its bad; and reference the frysk bug
> number; and post it here :-)
Yes please! :)
> > As far as I can see this change makes it so that a SIGCHLD is send to
> > the Thread calling sendAttach(). Why do we want to do that? Is that
> > Thread special. And if so, how does it react to a SIGCHLD?
> >
> PS: Kernel doesn't send frysk a SIGCHLD, notifying of the presence of
> waitpid event, when attaching to a suspended process.
Aha. So we are trying to trick our own waitpid() into thinking it
received a new SIGCHLD event? But aren't we actually waiting for a
SIGSTOP from the child after an ptrace attach?
Is sending the signal to our calling Thread as good as sending to any
other Thread in our frysk process? I am slightly surprised that the
signal arrives in a way that waitpid() is detecting it, since this isn't
a real SIGCHLD/SIGSTOP signal from the task we want to attach to. How
precisely does this work?
Cheers,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
2006-10-11 21:26 ` Mark Wielaard
@ 2006-10-11 21:39 ` Nurdin Premji
2006-10-11 22:33 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Nurdin Premji @ 2006-10-11 21:39 UTC (permalink / raw)
To: Mark Wielaard, cagney, frysk
> > Nurden, I would greatly expand the comment though, make it more blunt,
> > and prefix with XXX so we know its bad; and reference the frysk bug
> > number; and post it here :-)
/*
* XXX: Linux kernel has a 'feature' that if a process is already
* stopped and ptrace requests that it be stopped (again) in order to
* attach to it, the signal (SIGCHLD) notifying frysk of the attach's
* pending waitpid event isn't generated.
*/
/*
* XXX: This line sends another signal to frysk notifying about the
* attach's pending waitpid regardless of whether the task is running or
* stopped. This avoids hangs on attaching to a stopped process. Bug
* 3316.
*/
Here is my understanding of what the problem is and what I've done.
(Okay so the technical parts have been stolen from cagney's explanation)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
2006-10-11 21:26 ` Mark Wielaard
2006-10-11 21:39 ` Nurdin Premji
@ 2006-10-11 22:33 ` Andrew Cagney
2006-10-12 9:17 ` Mark Wielaard
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2006-10-11 22:33 UTC (permalink / raw)
To: Mark Wielaard; +Cc: frysk, npremji
Mark Wielaard wrote:
> Aha. So we are trying to trick our own waitpid() into thinking it
> received a new SIGCHLD event? But aren't we actually waiting for a
> SIGSTOP from the child after an ptrace attach?
>
>
A waitpid doesn not receive a SIGCHLD event, rather the arrival of a
waitpid event normally leads to the controlling process being sent a
SIGCHLD.
Nurden's patch, which is simple and elegant, fudges the case of SIGCHLD
not being sent by sending one anyway.
Andrew
> Is sending the signal to our calling Thread as good as sending to any
> other Thread in our frysk process? I am slightly surprised that the
> signal arrives in a way that waitpid() is detecting it, since this isn't
> a real SIGCHLD/SIGSTOP signal from the task we want to attach to. How
> precisely does this work?
>
> Cheers,
>
> Mark
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...
2006-10-11 22:33 ` Andrew Cagney
@ 2006-10-12 9:17 ` Mark Wielaard
0 siblings, 0 replies; 6+ messages in thread
From: Mark Wielaard @ 2006-10-12 9:17 UTC (permalink / raw)
To: Andrew Cagney; +Cc: frysk, npremji
On Wed, 2006-10-11 at 18:33 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > Aha. So we are trying to trick our own waitpid() into thinking it
> > received a new SIGCHLD event? But aren't we actually waiting for a
> > SIGSTOP from the child after an ptrace attach?
> >
> A waitpid doesn not receive a SIGCHLD event, rather the arrival of a
> waitpid event normally leads to the controlling process being sent a
> SIGCHLD.
Aha! That explains our PollWaitOnSigChld SignalEvent handler in
LinuxHost. I had never understood this step. Finally all the pieces are
starting to come together and make sense. I always assumed a SIGCHLD was
only send for child terminated events.
Still surprising we have kind of a double bookkeeping here. For each
(traced) child event we get a signal and we have to poll waitpid().
That does sound like high overhead.
> Nurden's patch, which is simple and elegant, fudges the case of SIGCHLD
> not being sent by sending one anyway.
OK, that just leaves one question:
> > Is sending the signal to our calling Thread as good as sending to any
> > other Thread in our frysk process?
Since we use tkill() on the calling Thread that seems to mean we are
explicitly sending to a particular task and that might not be the one
that has installed the signal handler. So how does that get at the right
place?
BTW. Slightly related, there is a bug/enhancement report for libgcj to
provide signal chaining:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
And another one for adding a wait handling hook:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
Those might be nice for us, so we can use more of the standard core
library. But I don't believe anybody is working on those atm.
Cheers,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-10-12 9:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20061011195727.26918.qmail@sourceware.org>
2006-10-11 20:13 ` frysk-core/frysk/proc LinuxTask.java TestProcS Mark Wielaard
2006-10-11 20:57 ` Andrew Cagney
2006-10-11 21:26 ` Mark Wielaard
2006-10-11 21:39 ` Nurdin Premji
2006-10-11 22:33 ` Andrew Cagney
2006-10-12 9:17 ` Mark Wielaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).