Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007045 [Squeak] Morphic minor random 05-15-08 05:40 05-26-08 18:34
Reporter wiz View Status public  
Assigned To KenCausey
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0007045: RenderBugz tests revised to avoid extraneous timing issues.
Description Ken has reported (on the 3.10 release mailling list may-2008)
that after running the test suite once, running it a second time causes the renderbug tests to fail on a random basis.
Additional Information the tests are checking for infinite recursion by setting time limits on blocks of code.
The timing was set as short as possible ( 1 ms). And would fail occasionally at that setting.

A 2 ms the test now passed consistenly on ken's testing configuration.

So I have rewritten the tests to all use the same parameterized length of time for the test. And set that parameter to 2ms.

It could be set higher but it is a better test the lower we can keep the limit.

I also put in a control test which will definitely not recurse. And use the 1 ms timing for the test. A failure of that test points to something external (to the tests) delaying things.


Ah, it just occured to me whats different between the first run and later runs. In later runs something we do in the test would be much more likely to set off a gc sequence. I wonder it that is what's happening?

Any revised tests. One parameter to change to solve problems if they should arise.

Yours in curiosity and ser vice, --Jerome Peace

Attached Files  RenderBugzM7045.st [^] (4,669 bytes) 05-16-08 03:01

- Relationships

SYSTEM WARNING: Creating default object from empty value

related to 0007036closed KenCausey Issue fix for 0006805 "Time now return fraction not integer" in 3.10.1 
related to 0007035closed edgardec Fix system version for 3.10.1 

- Notes
(0012097 - 318 - 366 - 366 - 366 - 366 - 366)
wiz
05-16-08 01:44

Hmmm, I found kens problem.

In a fresh 7159
get a sunit runner
select just RenderBugz.
Run them repeatedly.
The tests pass or fail randomly when set a 1 ms. So the time to run the test or the show boxes or something is causing the timing not to work sometime when the timing is 1 ms.

So definitely try 2 ms.
 
(0012098 - 77 - 109 - 109 - 109 - 109 - 109)
wiz
05-16-08 03:02

"fix begin"
Installer mantis bug: 7045 fix: 'RenderBugzM7045.st'.
"fix end"
 
(0012099 - 1357 - 1488 - 1488 - 1488 - 1488 - 1488)
wiz
05-16-08 03:06

The patch RenderBugzM7045.st fixes several problems.

The end of class comment for revision notes:
Revision notes. wiz 5/15/2008 22:58

When running tests from the TestRunner browser the test would sporadically fail.
When they failed a transfomation morph would be left on the screen and not removed by the ensureBlock.

So I changed things to fall under MorphicUIBugTests because that had a cleanup mechansizm for left over morphs.

I also added one routine to test for time and one parameter to determine the time limit.
To my surprise doubling or tripling the time limit still produced sporadic errors when the test is run repeatedly enough.
 ( I am using a 400mz iMac. )
So now the parameter is set to 4.
Things will probably fail there if tried long enough.
At that point try 5 etc.

I am reluctant to make the number larger than necessary. The tighter the test the more you know what is working.

I also added a dummy test to check specifically for the timing bug. It fails on the same sporadic basis as the other test when the time parameter is short enough. This lends confidence to the theory that the timing difficulty is coming from outside the test. The sunit runner puts up a progress morph for each test. So the morphic display stuff is busy and probably also the GC.

Yours in service and curiosity, --Jerome Peace
 
(0012100 - 119 - 143 - 143 - 143 - 143 - 143)
wiz
05-16-08 03:08

Reminder sent to: KenCausey

Hi ken,

You we're right about the problems. When run from the Sunit UI they show up quite a lot.

Here is the fix.
 
(0012115 - 253 - 253 - 253 - 253 - 253 - 253)
KenCausey
05-18-08 19:49

I still don't understand why it is desirable to have a small value for the delay timeout since it seems any value sufficiently smaller than infinity all has the same meaning. Nonetheless I agree that the RenderBugzM7045.st of 5/16/08 is an improvement.
 
(0012133 - 58 - 58 - 58 - 58 - 58 - 58)
KenCausey
05-21-08 14:13

Harvested by Edgar as update 7165RenderBugz-M7045-wiz.1.cs
 
(0012138 - 869 - 947 - 947 - 947 - 947 - 947)
wiz
05-22-08 04:06

Hi Ken,

I know of two reasons.
I would like the failing tests to fail as quickly as possible (w/o false positives of course).

The difficulty of making the test fail at each time point shows me something about how the system operates that I didn't know before.

Since the test can always be adjust edby changing one parameter it is more useful to step thru the times slowly and see how small they can be without causing the failures. Something is learned.

If I wasn't curious, then a large value for the time limit would be perfectly reasonalbe.

Since it seems to stop failing at 5 ms on my 400mhz IMac I suspect that time will work on most of the systems that try to run squeak. And if not I hope people will read the class comment and make the appropriate adjustments. And or add to this mantis report.

Yours in Curiosity and Service, --Jerome Peace
 
(0012149 - 151 - 151 - 151 - 151 - 151 - 151)
KenCausey
05-23-08 21:00

Oops, I mistakenly harvested this again as update 7172. This is a stupid duplication but my version categorizes the methods so is a minor improvement.
 
(0012174 - 15 - 15 - 15 - 15 - 15 - 15)
KenCausey
05-26-08 18:34

Fixed in 3.10.1
 

- Issue History
Date Modified Username Field Change
05-15-08 05:40 wiz New Issue
05-16-08 01:44 wiz Note Added: 0012097
05-16-08 03:01 wiz File Added: RenderBugzM7045.st
05-16-08 03:02 wiz Note Added: 0012098
05-16-08 03:06 wiz Note Added: 0012099
05-16-08 03:08 wiz Issue Monitored: KenCausey
05-16-08 03:08 wiz Note Added: 0012100
05-18-08 18:03 KenCausey Relationship added related to 0007036
05-18-08 19:49 KenCausey Note Added: 0012115
05-20-08 19:20 KenCausey Status new => assigned
05-20-08 19:20 KenCausey Assigned To  => KenCausey
05-20-08 22:48 KenCausey Relationship added related to 0007035
05-21-08 14:13 KenCausey Status assigned => resolved
05-21-08 14:13 KenCausey Fixed in Version  => 3.10
05-21-08 14:13 KenCausey Resolution open => fixed
05-21-08 14:13 KenCausey Note Added: 0012133
05-22-08 04:06 wiz Note Added: 0012138
05-23-08 21:00 KenCausey Note Added: 0012149
05-26-08 18:34 KenCausey Status resolved => closed
05-26-08 18:34 KenCausey Note Added: 0012174


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
85 total queries executed.
53 unique queries executed.
Powered by Mantis Bugtracker