488597 - Random Test Failure (test_punycodeURIs.js) - Nothing to do with trunk 64 bit builds

Reporter

Description

•

16 years ago

TEST-UNEXPECTED-FAIL | e:\builds\moz2_slave\mozilla-1.9.1-win32-unittest\build\objdir\_tests\xpcshell\test_uriloader_exthandler\unit\test_punycodeURIs.js | test failed, see following log: TEST-UNEXPECTED-FAIL | e:\builds\moz2_slave\mozilla-1.9.1-win32-unittest\build\objdir\_tests\xpcshell\test_uriloader_exthandler\unit\test_punycodeURIs.js | Expected File e:\builds\moz2_slave\mozilla-1.9.1-win32-unittest\build\objdir\_tests\xpcshell\test_uriloader_exthandler\unit\result.txt does not exist http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1239827982.1239835683.817.gz&fulltext=1 WINNT 5.2 mozilla-1.9.1 unit test on 2009/04/15 13:39:42

Shawn Wilsher :sdwilsh

Reporter

Updated

•

16 years ago

Whiteboard: [orange]

Mark Banner (:standard8)

Assignee

Comment 1

•

16 years ago

Hmm, I've seen this occasionally on the TB boxes (and not got round to filing it :-( ), there's a one-second timeout where it waits just after calling launchWithURI (which launches a very small exe based on WriteArgument.cpp), I wonder if that's enough of a delay or if something really is going wrong.

URL: http://mxr.mozilla.org/comm-central/s...

Shawn Wilsher :sdwilsh

Reporter

Comment 2

•

16 years ago

Is there any way you can determine when the exe is done doing whatever you wanted it to do? Timeouts are unpredictable because the unit test slaves are really really slow sometimes.

Mark Banner (:standard8)

Assignee

Comment 3

•

16 years ago

(In reply to comment #2) > Is there any way you can determine when the exe is done doing whatever you > wanted it to do? I don't think so, unless we can do reliable process detection cross platform. I'm currently thinking we should just adjust the timeout methods, I'll come up with a patch in a while.

Mark Banner (:standard8)

Assignee

Comment 4

•

16 years ago

Attached patch The fix — Details — Splinter Review

This patch changes the test so that if the file doesn't exist, it retries up to 30 times/seconds. This should reduce the possible cases where we fail, and if we pass we'll only wait as long as we need to rather than the full 30 seconds. I don't see any other way to do this without timeouts.

Assignee: nobody → bugzilla

Status: NEW → ASSIGNED

Attachment #378046 - Flags: review?(sdwilsh)

Shawn Wilsher :sdwilsh

Reporter

Comment 5

•

16 years ago

Comment on attachment 378046 [details] [diff] [review] The fix Hrm, yeah. This is probably the best option we have available to us for now. sadface. This technically needs sr, but I'm not sure anybody will care.

Attachment #378046 - Flags: review?(sdwilsh) → review+

Mark Banner (:standard8)

Assignee

Comment 6

•

16 years ago

Checked in: http://hg.mozilla.org/mozilla-central/rev/d1abfc97c140 I'll push to 1.9.1 later assuming it sticks.

Status: ASSIGNED → RESOLVED

Closed: 16 years ago

Resolution: --- → FIXED

Mark Banner (:standard8)

Assignee

Comment 7

•

16 years ago

Checked in to 1.9.1 (test-only fix): http://hg.mozilla.org/releases/mozilla-1.9.1/rev/edee09521af4

Keywords: fixed1.9.1

Target Milestone: --- → mozilla1.9.1

Steffen Wilberg

Comment 8

•

16 years ago

Comment on attachment 378046 [details] [diff] [review] The fix >+// Try several times in case the box we're running on is slow. >+const kMaxCheckExistAttempts = 30; // seconds >+var gCheckExistsAttempts = 0; >+ > function checkFile() { >+ if (!tempFile.exists()) { >+ if (gCheckExistsAttempts >= kMaxCheckExistAttempts) { >+ do_throw("Expected File " + tempFile.path + " does not exist after " + >+ kMaxCheckExistAttempts + " seconds"); >+ } >+ else { >+ // Wait a bit longer then try again >+ do_timeout(1000, "checkFile()"); Did you forget to increment gCheckExistsAttempts somewhere?

Mark Banner (:standard8)

Assignee