Re: Make TestBreakpoints deterministic

[Mark Wielaard <mark at klomp dot org>]

Hi Andrew,

On Mon, 2006-08-21 at 13:39 -0400, Andrew Cagney wrote:
> > If we startup the eventloop again "too soon" what happens is that we see
> > the proc/task again when we do a Manager.host.requestRefreshXXX(). This
> > adds the proc as detached to the core. But the kernel still has a
> > terminate event pending for us from when we were actually attached to it
> > (which seems to be the reason the proc is still around). So we must
> > really make sure that we have received all events from the kernel,
> > including the terminated event, even after we have detached already.
> >   
> That's the bug then - the original tearDown didn't detach frysk from 
> those processes, presumably because it didn't know that it needed to?

No teardown does kill and then detach from the process. It is just that
that doesn't prevent the kernel from sending us a terminated event for
that process later anyway. This never happened with the fc5 kernels, but
seems to happen with the recent fc6 kernels.

> The TestLib.tearDown code iterates over a list of registered processes 
> brute force detaching and killing each in turn.  Provided the relevant 
> processes are registered then all should be good.  The eventLoop should 
> certainly not be running at the time tearDown is reached - a bug in the 
> test case; and needing to add sleep just tells us that the test is 
> non-deterministic :-(

The eventloop isn't running during teardown. It is just that the kernel
for whatever reason decides we might still be interested in the
terminated event later even though we are already detached. So before we
restart the eventloop we need to make sure we have really seen this
process disappear because otherwise we risk the kernel letting us know
about that event at some later point in time. So we cannot rely on just
the kills and detaches of the teardown for procs we have been attached
to.

Cheers,

Mark