Sporadic timeout waiting for onload, in crashtests 421715-1.html and 458637-1.html on WINNT 5.2 mozilla-central unit test box

RESOLVED DUPLICATE of bug 473680

Status

()

Core
Canvas: 2D
RESOLVED DUPLICATE of bug 473680
9 years ago
9 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

The crashtest content/canvas/crashtests/421715-1.html just sporadically timed out on the WINNT 5.2 mozilla-central unit test box.

Log: 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232118184.1232124071.12615.gz

Test source:
http://mxr.mozilla.org/mozilla-central/source/content/canvas/crashtests/421715-1.html

I'm assuming it's sporadic because the only changes since the previous green cycle were these two icon-file tweaks:
 http://hg.mozilla.org/mozilla-central/rev/fb65fb0cb7a6
 http://hg.mozilla.org/mozilla-central/rev/89de1e025c5a

If this sporadic timeout continues to be a problem, we should figure out what's going on and fix it.
The test "458637-1.html" failed to load as well, immediately before this one... And the log actually says we timed out waiting for onload to fire, so presumably none of those tests' JS had even been run yet.

So, that's quite strange...  Maybe the box had a temporary spike in CPU usage due to another process running in the background, or something...?
The other test's source is:
http://mxr.mozilla.org/mozilla-central/source/content/base/crashtests/458637-1.html
Summary: Sporadic crashtest timeout in 421715-1.html on WINNT 5.2 mozilla-central unit test box → Sporadic timeout waiting for onload, in crashtests 421715-1.html and 458637-1.html on WINNT 5.2 mozilla-central unit test box
(In reply to comment #1)
> And the log actually says we timed out waiting for onload to fire, so
> presumably none of those tests' JS had even been run yet.

no, I lied -- the tests' JS is triggered by the _body_'s onload, which is different from the onload mentioned in the log message.  So, the tests are getting to run their JS after all.

I think this is most likely that the JS in these tests took too long to complete.
FWIW, these two tests actually failed in 3 cycles out of 7 consecutive cycles on the windows unittest box. (those 3 being the cycle I originally filed this bug for, plus these two earlier ones:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232114553.1232123918.12160.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232109381.1232114143.23009.gz
)

However, they passed in the most recent cycle.
These two tests failed again:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232147140.1232152774.6017.gz
OS X 10.5.2 mozilla-central unit test on 2009/01/16 14:22:49
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232156322.1232163393.30929.gz
WINNT 5.2 mozilla-central unit test on 2009/01/16 17:38:42

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232163600.1232170747.11844.gz
WINNT 5.2 mozilla-central unit test on 2009/01/16 19:40:00
Duplicate of bug 473680 !?
Yeah, looks like basically the same issue described in bug 473680 comment 6.

Note that the second test from this bug here (421715-1.html) doesn't use *any* setTimeouts.  So if this problem is setTimeout-related (as suggested by the title of bug 473680), then it seems that it's the setTimeouts in the *first* test which end up making the subsequent test time out.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 473680
(In reply to comment #8)
> Yeah, looks like basically the same issue described in bug 473680 comment 6.
> 
> Note that the second test from this bug here (421715-1.html) doesn't use *any*
> setTimeouts. [...]
(FWIW, I just noticed that I actually already partly described this in bug 473680 comment 11)
You need to log in before you can comment on or make changes to this bug.