Patricia Shanahan wrote:
On 8/22/2010 2:15 PM, Patricia Shanahan wrote:
On 8/21/2010 10:17 PM, Patricia Shanahan wrote:
...
Tomorrow, unless I get a better idea or someone posts one, I'll start a
binary search. The objective will be to find consecutive revisions N
and
N+1 such that N passes the servicediscovery tests and N+1 fails them.
...
I have preliminary results from the binary search. I can't narrow it
down to a single check-in because I cannot build revision 934802. The
indications are that revision 934258 is the last buildable revision that
passes and revision 935130 is the first buildable revision that fails.
This is based on a single test,
com/sun/jini/test/impl/servicediscovery/event/NotifyEventDropProxyTaskRace.td,
that I had previously found to be solidly failing on repeated runs on
the latest revision.
I'm in the process of running the full QA tests, servicediscovery
included, to see if the other failing tests behave the same way.
Both sets of servicediscovery tests have completed, with zero failures
for 934258 and ten failures for 935130, confirming that the entire set
of servicediscovery failures in the head revision should be attributed
to the changes between those two revisions.
The failures seem to me to be too solidly reproducible, without any
added delays, to be likely to be race conditions, even though that is
what several of the failing tests were originally designed to
demonstrate.
Patricia
Thanks Patricia, that's very helpful, I'll figure it out where I went
wrong this week, it really shows the importance of full test coverage.
Much appreciated,
Peter.
