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:
(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?
Not that I know of. Bug 599478 may be the root cause though.
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.
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.
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?
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.
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
We should be able to reenable these tests now.
Looks to me like they were reenabled by http://hg.mozilla.org/mozilla-central/rev/861afa477aba .
Assignee: nobody → joshmoz
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Depends on: 600777
Depends on: 602140
You need to log in before you can comment on or make changes to this bug.