Closed Bug 805639 Opened 12 years ago Closed 12 years ago

Intermittent devtools/webconsole/test/test_file_uri.html | file URI match

Categories

(DevTools :: Console, defect)

Product:
DevTools
Component:
Console
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g18 fixed, b2g18-v1.0.1 unaffected)

Status:
RESOLVED FIXED
Milestone:
Firefox 19
Tracking Flags:
Tracking Status
b2g18 --- fixed
b2g18-v1.0.1 --- unaffected

People

(Reporter: philor, Assigned: msucan)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

proposed fix
1022 bytes, patch
paul
: review+
Details | Diff | Splinter Review 
First instance seems to have been where I misstarred as bug 803991 in https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=0bbc68396695, dunno whether it's actually somehow the result of that push.

https://tbpl.mozilla.org/php/getParsedLog.php?id=16464197&tree=Mozilla-Inbound
Rev5 MacOSX Mountain Lion 10.8 mozilla-inbound debug test mochitest-other on 2012-10-25 11:49:20 PDT for push 0bbc68396695
slave: talos-mtnlion-r5-063

29781 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html | the temporary file was saved successfully
++DOCSHELL 0x15427a290 == 9 [id = 500]
++DOMWINDOW == 34 (0x15427ada0) [serial = 2063] [outer = 0x0]
WARNING: Subdocument container has no frame: file ../../../layout/base/nsDocumentViewer.cpp, line 2385
++DOMWINDOW == 35 (0x1542a8c70) [serial = 2064] [outer = 0x15427ad20]
++DOMWINDOW == 36 (0x153011820) [serial = 2065] [outer = 0x15427ad20]
29782 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html | fileActivity actor
29783 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html | file URI match
29784 INFO TEST-END | chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html | finished in 406ms

https://tbpl.mozilla.org/php/getParsedLog.php?id=16464329&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=16466786&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=16466181&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=16466870&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=16468449&tree=Mozilla-Inbound
OS: Windows XP → All
Hardware: x86 → All
Attached patch proposed fix — — Splinter Review 
Problem: for some reason the temporary file is not always removed from the temp folder, and we get a slightly different file name when the same file name already exists. This patch relaxes the file name patch. Should work.
Assignee: nobody → mihai.sucan
Status: NEW → ASSIGNED
Attachment #675595 - Flags: review+
> This patch relaxes the file name patch.

erm, .... file name regex match.
Or, once in a while, you get

https://tbpl.mozilla.org/php/getParsedLog.php?id=16488980&tree=Firefox

29924 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html | an unexpected uncaught JS exception reported through window.onerror - NS_ERROR_FILE_IS_LOCKED: Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsILocalFile.remove] at chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/test_file_uri.html:82 

Which makes me wonder if I was looking for the wrong sort of things when I was looking for something that might have landed to break it.
(In reply to Phil Ringnalda (:philor) from comment #10)
> Or, once in a while, you get
> 
> https://tbpl.mozilla.org/php/getParsedLog.php?id=16488980&tree=Firefox
> 
> 29924 ERROR TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/
> test_file_uri.html | an unexpected uncaught JS exception reported through
> window.onerror - NS_ERROR_FILE_IS_LOCKED: Component returned failure code:
> 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsILocalFile.remove] at
> chrome://mochitests/content/chrome/toolkit/devtools/webconsole/test/
> test_file_uri.html:82 
> 
> Which makes me wonder if I was looking for the wrong sort of things when I
> was looking for something that might have landed to break it.

Shouldn't NetUtil.asyncCopy close the output stream at the end? Why is it locked only sometimes? This error makes me wonder if I should call FileUtils.closeSafeFileOutputStream() myself...
Two things I'd like to note:

- bug 803991 landed after this failure started appearing. First I thought my patch caused this, but not really. The first failures do not show the info() message with the file URI that I added in bug 803991.

- asyncCopy() must close the input and output streams at the end of the operation (based on docs). Did this regress recently?
https://hg.mozilla.org/mozilla-central/rev/e7ef0d64a8a7
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
Whiteboard: [orange]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: