This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]