Re: Kill and refresh

[Mark Wielaard <mark at klomp dot org>]

Hi Andrew,

On Fri, 2006-07-14 at 01:10 -0400, Andrew Cagney wrote:
> A detached process shouldn't be generating a terminated event;

OK, that is what I expected. I have also seen this happen in the
disappeared state. I assume Terminated events should also not happen in
that state?

>  ah, it 
> looks like it is a detached child process - can you check the parent-pid 
> of the process to see what it is?

I am a bit confused by what parent-pid it has. It seems to have a ppid
that doesn't exist (anymore). I assume this is because we start the
process with Fork.daemon(), so it has has ppid our forked process that
is no longer there. I had assumed that would mean that the ppid would be
zero. This is different from when we create the process with
Fork.exec(), then it has a ppid the process id/main thread id of our
process.

>     I suspect the wait-pid is comming 
> from the child exiting, rather than it being some how attached.  
> Consequently, I'm not sure if it should be treated as a bug or wart?

According to Wait.log() we are seeing three waitpids with:
pid: 0, status: 1be660, errno: 0
pid: 32500, status: 0, errno: 0
pid: -1, status: b73b1300, errno: 10

Where 32500 is the non-existing process described above.

> For reference I'll provide some commentary on the code (but the above is 
> more interesting):
> There's 
> http://sourceware.org/frysk/javadoc/private/frysk/proc/TestLib.html#killDuringTearDown:int

Thanks. While writing some tests I seem to be duplicating functionality
of TestLib. Will cleanup and use that.

> > +  public void setUp()
> > +  {
> >   
> super.setUp ();

Similar as above. But this time I knew and explicitly didn't want to use
it to get a more minimal testcase to see if I better understood what
went wrong where. So I didn't wanted to add extra observers if not
absolutely necessary.

> You'll want a way of knowing that the funit-loop process is really 
> running, funit-child, for instance, does this be sending frysk a 
> signal(2) once it is fully set up - frysk runs the event loop until it 
> sees that signal.

Yes, I actually have an addition to Fork which just gives you an
Input/OutputStream to the process to communicate with. I found that a
little more convenient then using signals. I'll post it to the list so
you can see if that is something we might want to add.

> > +    ProcId procId1 = new ProcId(pid1);
> > +
> > +    // Try to find it
> > +    Manager.host.requestRefreshXXX(true);
> >   
> Call runPending() here, it will process the refresh.

Right. But... that was the confusing thing. I could only get this weird
failure when running the EventLoop in a separate Thread. When
starting/stopping/resuming the EventLoop on the same thread things do
seem to go forward without getting the weird state transitions of the
tasks. That was why I started writing this testcase in the first place
to understand where/when exactly I would get such unexpected
TerminateEvents.

> > +    // No, lets kill it...
> > +    Signal.kill(pid1, Sig.KILL);
> >   
> This should generate an event.
> 
> You just want to know that the event has been received and processed.  
> Will this event have an effect that can be observed?  If there is, add 
> an observer to it, and then when it occures, request the event loop to 
> shut down.

Right again, but I wanted to test what happened when a signal was send
to a process that wasn't attached. And when I add an observer then the
process will become attached. So it then is in a different state then I
was interested in.

> > +int
> > +main (int argc, char **argv)
> > +{
> > +  // Happily count to infinity
> > +  int i = 0;
> > +  while(1)
> > +    i++;
> > +
> > +  return 0;
> > +}
> >   
> suggest having a timer as well (default 5 seconds) so that if frysk 
> crashes this isn't left around (at least long term).

Good point. Added that with a simple alarm.

Cheers,

Mark