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

Status: RESOLVED DUPLICATE of bug 473680

(Core :: Graphics: Canvas2D, defect)

Description

[Daniel Holbert [:dholbert]]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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...?

Comment 2

[Daniel Holbert [:dholbert]]

The other test's source is:
http://mxr.mozilla.org/mozilla-central/source/content/base/crashtests/458637-1.html

Comment 3

[Daniel Holbert [:dholbert]]

(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.

Comment 4

[Daniel Holbert [:dholbert]]

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.

Comment 5

[Daniel Holbert [:dholbert]]

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

Comment 6

[Daniel Holbert [:dholbert]]

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

Comment 7

[Serge Gautherie (:sgautherie)]

Duplicate of bug 473680 !?

Comment 8

[Daniel Holbert [:dholbert]]

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.

Comment 9

[Daniel Holbert [:dholbert]]

(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)