Intermittent test_0200_app_launch_apply_update.js | the application can't be in use when running this test

RESOLVED FIXED in mozilla2.0b7

Status

()

defect
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: rstrong, Assigned: rstrong)

Tracking

({intermittent-failure})

Trunk
mozilla2.0b7
x86
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1287561818.1287565825.24202.gz

SOURCE DIRECTORY c:\talos-slave\mozilla-central_win7_test-xpcshell\build\firefox\updates\0
DESTINATION DIRECTORY c:\talos-slave\mozilla-central_win7_test-xpcshell\build\firefox
NS_main: file in use - failed to exclusively open executable file: c:\talos-slave\mozilla-central_win7_test-xpcshell\build\firefox\updatetest.exe

<a name='err1'></a><font color='000080'>TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central_win7_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0200_app_launch_apply_update.js | the application can't be in use when running this test - See following stack:
notes: the file in use in this orange is a copy of firefox.exe named updatetest.exe. If there is a pre-existing file with this name it is removed. The only thing that comes to mind that might be an issue is Win Vista and above will treat a file with the string update in the name as an installer if it doesn't have a manifest though in this case the file does have a manifest. Wouldn't hurt to rename it to something that doesn't have update in it.
Also, the updatetest.exe file was removed successfully in end_test.
Summary: test_0200_app_launch_apply_update.js | the application can't be in use when running this test → Intermittent test_0200_app_launch_apply_update.js | the application can't be in use when running this test
Posted patch patch rev1Splinter Review
Renames the copy of the app binary for Windows to aus_test_app.exe since it is possible that the string update in the name is causing problems and makes the path to the app binary a lazy getter since this is likely caused by there being two calls to getAppBinPath each of which will create a copy of the app binary to be used when running on Windows.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #484724 - Flags: review?(dtownsend)
Comment on attachment 484724 [details] [diff] [review]
patch rev1

>-function getProcessArgs() {
>-  let appBinPath = getAppBinPath();
>-
>+function getProcessArgs(aAppBinPath) {

The argument doesn't seem to be necessary
Attachment #484724 - Flags: review?(dtownsend) → review+
Pushed to mozilla-central
https://bugzilla.mozilla.org/show_bug.cgi?id=605767
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
bah... meant to leave this open until I verify the fix worked.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Five consecutive successful runs! Resolving -> fixed
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.