[Windows] xpcshell-tests: test_bug_401430.js fails intermittently

RESOLVED FIXED in mozilla1.9.3a1



11 years ago
6 years ago


(Reporter: sdwilsh, Assigned: mak)



Windows Vista
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 .13-fixed, status1.9.1 .16-fixed)




(1 attachment)



11 years ago
The test is failing - could be not a long enough timeout, but it is a hardware box, so I'm suspect of that.
Blocks: 401430

Comment 1

10 years ago
today's failure on 1.9.1 branch:

is Bug 464326 the same?
Whiteboard: [orange]
Duplicate of this bug: 464326
WINNT 5.2 comm-1.9.1 unit test on 2009/06/12 13:36:30

TEST-UNEXPECTED-FAIL | e:\builds\slave\comm-1.9.1-win32-unittest\build\objdir\mozilla\_tests\xpcshell\test_dm\unit\test_bug_401430.js | false == true - See following stack:
JS frame :: e:\builds\slave\comm-1.9.1-win32-unittest\build\objdir\mozilla\_tests\xpcshell\test_dm\unit\test_bug_401430.js :: checkResult :: line 46

Code is:
45 function checkResult() {
46   do_check_true(checkRecentDocsFor(resultFileName));
Summary: test_bug_401430.js fails → [Windows] xpcshell-tests: test_bug_401430.js fails intermittently

Comment 9

10 years ago
WINNT 5.2 mozilla-central test everythingelse [testfailed] Started 15:32, finished 16:09
This test has been touched by Ted, Gavin and Ehsan, and is still failing. Any of you three have thoughts?

WINNT 5.2 mozilla-1.9.2 test everythingelse on 2009/09/29 04:12:41
My changes were mostly just a tree-wide refactoring, and then a followup fix to the test as fallout from that. The test checks that downloaded files get put into the "Recent Documents" list. My refactoring change accidentally caused the file to get downloaded to $TEMP, which apparently means the file doesn't go into "Recent Documents", so I changed the test to download to the test directory instead.

The test uses an arbitrarily-chosen 1000ms timeout, because apparently the change to the registry in response to the SHAddToRecentDocs call doesn't happen synchronously (our registry APIs can't get the new value immediately, anyways).

I'm not sure that there's much we can do to address this besides removing the test or just increasing the timeout.

Comment 13

9 years ago
we can use a polling strategy, check after 1000ms, if it's not present check again after 500ms or so, till we reach a max timing of 5s.

Comment 14

9 years ago
taking to try polling.
Assignee: nobody → mak77

Comment 15

9 years ago
Created attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]
Attachment #405495 - Flags: review?


9 years ago
Attachment #405495 - Flags: review? → review?(edilee)

Comment 16

9 years ago
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]

>--- a/toolkit/components/downloads/test/unit/test_bug_401430.js
> function checkResult() {
>   // delete the saved file (this doesn't affect the "recent documents" list)
>   var resultFile = do_get_file(resultFileName);
>   resultFile.remove(false);
>+  // Need to poll RecentDocs value because the SHAddToRecentDocs call
>+  // doesn't update the registry immediately.
>+  do_timeout(POLL_REGISTRY_TIMEOUT, "pollRecentDocs();");
I suppose you could just call pollRecentDocs() instead of on a timeout, but you can leave as is.

Attachment #405495 - Flags: review?(edilee) → review+

Comment 17

9 years ago
yes but i prefer giving some breath to the main thread in tests, and i really doubt the value will be in the registry immediately. so i did that

Comment 18

9 years ago
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
status1.9.1: --- → ?
Flags: wanted1.9.2?
Flags: in-testsuite+
Bug still on m-1.9.1:
WINNT 5.2 comm-1.9.1 unit test on 2010/08/31 09:31:57
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]

Attachment #405495 - Attachment description: patch v1.0 → patch v1.0 [Checked in: Comment 18 & 20]
status1.9.2: --- → .12-fixed
Flags: wanted1.9.2?
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]

Attachment #405495 - Attachment description: patch v1.0 [Checked in: Comment 18 & 20] → patch v1.0 [Checked in: Comment 18 & 20 & 21]
status1.9.1: ? → .15-fixed
Depends on: 607005
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.