|Anonymous | Login||10-23-2020 21:47 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ 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|
|ETA||none||Fixed in Version||3.10||Product Version|
|Summary||0007045: RenderBugz tests revised to avoid extraneous timing issues.|
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.
|Steps To Reproduce|
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|
SYSTEM WARNING: Creating default object from empty value
(0012097 - 318 - 366 - 366 - 366 - 366 - 366)
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)
Installer mantis bug: 7045 fix: 'RenderBugzM7045.st'.
(0012099 - 1357 - 1488 - 1488 - 1488 - 1488 - 1488)
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)
Reminder sent to: KenCausey
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)
|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)
|Harvested by Edgar as update 7165RenderBugz-M7045-wiz.1.cs|
(0012138 - 869 - 947 - 947 - 947 - 947 - 947)
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)
|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)
|Fixed in 3.10.1|
|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.