This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: Make TestBreakpoints deterministic
Hi Andrew,
On Tue, 2006-08-22 at 10:38 -0400, Andrew Cagney wrote:
> > O, that makes sense. The only strange thing is that we didn't see that
> > happening on fc5 kernels. But you are right, in this case it is indeed a
> > real child process so we must wait for the traditional waitpid child
> > stuff. I have updated the comments in the code to make that clear.
> >
> I'm not sure adding comments is helping the tear-down code. The patch
> added:
>
> public void tearDown()
> {
> + // Make sure proc is gone.
> + synchronized (monitor)
> + {
> + while (!procTerminated)
> + {
> + try
> + {
> + monitor.wait();
> + }
> + catch (InterruptedException ie)
> + {
> + // Ignored
> + }
> + }
> + }
> +
> // Make sure event loop is gone.
> eventloop.requestStop();
> synchronized (monitor)
> @@ -125,6 +151,22 @@
> super.tearDown();
> }
>
> + // Called by the Host when procs are removed.
> + // Used to monitor whether or not our proc has truely left the building.
> + public void update(Observable o, Object obj)
> + {
> + Proc p = (Proc) obj;
> + if (p.equals(proc))
> + {
> + synchronized (monitor)
> + {
> + procTerminated = true;
> + monitor.notifyAll();
> + }
> + }
> + }
> +
>
> and, unless I'm mistaken, that can only work if the event loop is still
> running in its own thread (you seem to think otherwise?)
No, at that time the eventloop is running. Otherwise it wouldn't work as
you said.
> Studying TestLib.tearDown, I find the sequence:
>
> - send SIGKILL
> - send SIGCONT
> - send DETACH+KILL
>
> and then:
>
> - block-wait until no children (because all exited, or ECHLD)
>
> The interesting part is
>
> public void terminated (int pid, boolean signal,
> int value, boolean
> coreDumped)
> {
> children.remove(new Integer(pid));
> }
> public void disappeared (int pid, Throwable w)
> {
> detach (pid);
> children.remove(new Integer(pid));
> }
>
> notice how it is removing each child when it sees an exit event, yet
> here the child is going to generate two exit events.
Right, but that is what we expect isn't it? Since we expect this process
to give us 2 terminated events, one through ptrace/wait and one because
it is a child.
Cheers,
Mark