Closed Bug 605767 Opened 14 years ago Closed 14 years ago

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

Categories

(Toolkit :: Application Update, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b7

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

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
Attached 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+
Status: ASSIGNED → RESOLVED
Closed: 14 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: 14 years ago14 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.

Attachment

General

Created:
Updated:
Size: