Closed
Bug 599477
Opened 14 years ago
Closed 14 years ago
test_0110_general.js, test_0111_general.js, test_0112_general.js fail on 10.5 from a i386+x86_64 universal build
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b7
People
(Reporter: nthomas, Assigned: jaas)
References
Details
Attachments
(1 obsolete file)
Originally found in bug 598507 comment #19, where there's a log at attachment 477805. We're switching from ppc+i386 universal to i386+x86_64 universal in bug 571367, and are planning to temporarily disable these tests for that. Basically we need to make sure we launch the i386 arch of any util the test uses, when running on 10.5. TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0110_general.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0110_general.js | 256 == 0 - See following stack: TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0111_general.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0111_general.js | 256 == 0 - See following stack: TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0112_general.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard_test-xpcshell/build/xpcshell/tests/toolkit/mozapps/update/test/unit/test_0112_general.js | 256 == 0 - See following stack:
Comment 1•14 years ago
|
||
(In reply to comment #0) > Originally found in bug 598507 comment #19, where there's a log at attachment > 477805 [details]. We're switching from ppc+i386 universal to i386+x86_64 universal in bug > 571367, and are planning to temporarily disable these tests for that. Basically > we need to make sure we launch the i386 arch of any util the test uses, when > running on 10.5. Why is that the case? Is nsIProcess not doing the right thing? If so, is there a bug to get nsIProcess to do the right thing?
Reporter | ||
Comment 2•14 years ago
|
||
Not that I know of. Bug 599478 may be the root cause though.
Comment 3•14 years ago
|
||
nsIProcess clearly doesn't do the right thing (run the arch you're currently running). Doing it correctly is sort of a pain, since you probably have to verify that the binary contains the architecture you expect to want to run.
Comment 4•14 years ago
|
||
I wonder if going back to using PR_CreateProcess and PR_CreateProcessDetached as prior to bug 263429 being fixed would fix it. If not that or some other fix then nsIProcess is going to be busted under some usages. btw: I would hope that nsIProcess were able to launch both x86 / x64 processes no matter what arch the app is running under.
Comment 5•14 years ago
|
||
note to self... check the code especially if you haven't looked at it in a while. The updater is a bundle so I wonder if it would work to just pass "arch", "-arch", and "i386" for it and launch the bundle instead?
Reporter | ||
Comment 6•14 years ago
|
||
I was going to suggest that updater.app should use the same Info.plist trick as on the main app, and set 10.6 as the minimum requirement to run 64bit. Then I discovered it already does.
Comment 8•14 years ago
|
||
Josh, thanks for working on the bork'd nsIProcess. It would probably be best to file a core -> xpcom bug for fixing this and make this bug and the other bugs for the disabled tests that are broken due to nsIProcess not working properly depend on it.
Comment on attachment 479565 [details] [diff] [review] fix v1.0 Moving this work to bug 600711.
Attachment #479565 -
Attachment is obsolete: true
Comment 10•14 years ago
|
||
We should be able to reenable these tests now.
Comment 11•14 years ago
|
||
Looks to me like they were reenabled by http://hg.mozilla.org/mozilla-central/rev/861afa477aba .
Comment 12•14 years ago
|
||
They were.
Assignee: nobody → joshmoz
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
You need to log in
before you can comment on or make changes to this bug.
Description
•