[V3dot10] Re: Help needed with RenderBugz

[Ken Causey]

Extending the wait to 2 milliseconds (from 1) eliminates the failure so
as expected the problem is indeed timing related.  While this may simply
be happenstance (my computer, what else I'm doing, etc.) it may also be
due to the changes to DateAndTime class>now to re-enable sub-second
precision.  I'm going to spend a little time to determine if that's the
case.  But is there any reason not to change these tests (since the
primary purpose is to test for infinite recursion) to something more
like 10 milliseconds to ensure that they not fail in a wider array of
situations (think OLPC for example)?

Ken

On Mon, 2008-05-12 at 23:30 -0700, Jerome Peace wrote:
> Help needed with RenderBugz
> ***
> >Monday, May 12, 2008 4:22 PM
> >From:
> >"Ken Causey" <ken at kencausey.com>
> >
> >To:
> >"Jerome Peace" <peace_the_dreamer at yahoo.com>
> >Cc:
> >"Discussion about development of Squeak 3.10"
> ><v3dot10 at lists.squeakfoundation.org>
> >Message contains attachments
> >
> >I made the changes related to the time issues and now when I rerun all
> >the tests I get a new failure on RenderBugz.  Rerunning all the tests
> >seems to consistently result in a failure on RenderBugz, but not
> >necessarily the same test each time.  Also for some reason I can't debug
> >failures on these tests.  If I run each individually it works just fine.
> >Similarly if I run the entire RenderBugz testcase it works.  These tests
> >use timing as part of the test and I suspect that's where the problem
> >is, but I'm not certain as there are multiple failure modes and I can't
> >seem to get any information as to how exactly it failed.  Help would be
> >appreciated.
> >
> 
> I am puzzled. I can't see why the tests should fail 
> if the patches are in place.
> And if that were the case the tests should fail consistenly.
> Are the failures due to the assertion or due to time running out?
> 
> The other thing you could try is to give a different time limit.  
> I used 1 millisecond because that should be enough. 
> 
> If some other process is running at the same time as the test and 
> at a higher priority it may be causing a delay where no delay is expected. That would account for the time part of the test failing.
> 
> How long does a GC take? 
> Add that to the time limit and see if the tests will always pass. 
> (But a gc during the tests should be a rarity. 
> And not as reproducible as you are suggesting.)
> 
> It would also point to something other than the test 
> being wrong with the recent fix.
> 
> There are possibly still tests that 
> do not return conditions to "standard" after being run.
> LanEnvBugs>>testIsFontAvailable is known to change 
> the default fonts w/o properly restoring them. 
> This causes the second pass of tests to work 
> differently than the first. 
> So removing that class before running tests might stablize things.
> 
> 
> Hth,
> 
> Yours in curiosity and service, --Jerome Peace
> 
> >Ken
> >
> >
> ***
> 
> 
> 
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/v3dot10/attachments/20080513/8c0659b9/attachment.pgp