Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla1.9.1

Status

Core Graveyard
File Handling
RESOLVED FIXED
8 years ago
a year ago

People

(Reporter: sdwilsh, Assigned: standard8)

Tracking

({fixed1.9.1, intermittent-failure})

Trunk
mozilla1.9.1
fixed1.9.1, intermittent-failure
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

8 years ago
Whiteboard: [orange]
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.
(Reporter)

Comment 2

8 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.
(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.
Created attachment 378046 [details] [diff] [review]
The fix

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

Comment 5

8 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+
Checked in: http://hg.mozilla.org/mozilla-central/rev/d1abfc97c140

I'll push to 1.9.1 later assuming it sticks.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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

Comment 8

8 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?
(In reply to comment #8)
> Did you forget to increment gCheckExistsAttempts somewhere?

Damn, yes I did. Thanks for picking up on that.
(Reporter)

Comment 10

8 years ago
(In reply to comment #8)
> Did you forget to increment gCheckExistsAttempts somewhere?
Bah!  How did I miss that?!  Thanks for catching that!
I just saw this on tryserver:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1280370935.1280371818.10867.gz

Does this look like it is the same problem?  Reopening for now.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Also saw this on the try build right after mine, so I don't believe it is my patch:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1280372958.1280373826.17793.gz
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
The 64-bit Snow Leopard 10.6.2 failures are NOT this bug, they are persistent failures, see bug 561350.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago7 years ago
Resolution: --- → FIXED
Summary: Random Test Failure (test_punycodeURIs.js) → Random Test Failure (test_punycodeURIs.js) - Nothing to do with trunk 64 bit builds
So I think the patch is missing a return after the do_timeout, and is therefore useless right now.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
OK, we already have bug 598794 about this problem. Closing this and using that.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED
Depends on: 598794
Keywords: intermittent-failure
Whiteboard: [orange]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.