Community
Participate
Working Groups
Looks like all the Mac tests fail because of this: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:216) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:193) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:101) Either use macosx-cocoa-x86_64 on this machine, or add -d32 when launching the tests.
Created attachment 195110 [details] patch
Markus, please approve this change. I've already fixed it for the I20110509-1200 build.
Looks good, let's hope it works ;-).
Yes, I tested it this morning and it seemed to fix the problem :-)
verified in I20110509-1200
The UI session tests fail because of JVM mismatch (64-bit vs 32-bit). The stack traces look like this: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:216) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:193) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:101) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:690) .... (see, for instance, http://fullmoon.ottawa.ibm.com/downloads/drops/I20110514-0800/testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.tests.session.SessionTests.txt ) The session tests launch a nested Eclipse session using regular os/ws/arch options. The following VM seems to be picked up: vm=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java I'd suggest to see if it is possible to either switch this computer to testing 64-bit stack or install 32-bit VM as default.
We pass -d32 as an extraVMArgs value when invoking the tests so the 32 bit version of the vm is used. extraVMargs=-XstartOnFirstThread -d32 Do the session tests not inherit the properties of the VM that launched them? I'm concerned that it's a bit late to change to running our tests on a 64 bit SDK versus the 32 bit one we've been using all year.
(In reply to comment #7) > We pass -d32 as an extraVMArgs value when invoking the tests so the 32 bit > version of the vm is used. > > extraVMargs=-XstartOnFirstThread -d32 > > Do the session tests not inherit the properties of the VM that launched them? Apparently they do not :-). Session test launch a separate process and explicitly re-use arguments such as os/ws/arch. They, for instance, don't inherit modified memory allocation arguments from the "outer" instance. > > I'm concerned that it's a bit late to change to running our tests on a 64 bit > SDK versus the 32 bit one we've been using all year. Is there an option to specify 32-bit JVM as default? Something under Applications -> Utilities -> Java Preferences?
(In reply to comment #8) > Is there an option to specify 32-bit JVM as default? Something under > Applications -> Utilities -> Java Preferences? Yes, you can reorder the VMs there, but unfortunately, this only affects /usr/bin/java, but not the /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java that Eclipse finds as default installed JRE. You can see this when you launch with -showversion. It also doesn't work when I try to launch e.g. the ControlExample. (In reply to comment #7) > I'm concerned that it's a bit late to change to running our tests on a 64 bit > SDK versus the 32 bit one we've been using all year. I don't think that's a bigger change than upgrading the OS and the VM.
Created attachment 196050 [details] patch to switch to macosx cocoa x86_64 for testing
Created attachment 196125 [details] patch
I reran the tests with this patch (to run with macosx cocoa x86_64) and the session tests still failed. I'm deferring this bug to RC3.
(In reply to comment #12) > I reran the tests with this patch (to run with macosx cocoa x86_64) and the > session tests still failed. I'm deferring this bug to RC3. Did they fail in the same way as in the comment 6?
Here are the results http://eclipsebuildserv.otttawa.ibm.com/downloads/bogus/downloads/drops/N20110518-1644/testresults/html/org.eclipse.ui.tests_macosx.cocoa.x86_5.0.html
sorry the link should have been http://eclipsebuildserv.ottawa.ibm.com/downloads/bogus/downloads/drops/N20110518-1644/testresults/html/org.eclipse.ui.tests_macosx.cocoa.x86_5.0.html
(In reply to comment #14) > Here are the results The session tests passed in this version, but there are 10 other tests that failed. Hmm...
Created attachment 196163 [details] Possible temporary workaround for session tests
Boris, could you try running session tests with the patch on your Mac?
Paul, could you try running Session tests with the "Possible temporary workaround" on Linux?
My tests all passed correctly. I'd suggest you switch to "Constants.ARCH_X86.equals(arch)" though. I know the JLS specs that all compiled string constants will be interned, but I believe something read into the properties is less reliable. PW
Created attachment 196451 [details] Possible temporary workaround Update1 Good point, patch updated.
The session tests passed for me with and without the patch on Windows XP (as expected). This looks safe to me.
I can confirm that the patch fixes the problem on Cocoa (using Mac OS X 10.6.7), and that the session tests fail when not running with the patch. Note that I had to add "-d32" to the arguments in the UI session tests launch configuration for the "outer" test instance to come up.
(In reply to comment #23) > ... Note > that I had to add "-d32" to the arguments in the UI session tests launch > configuration for the "outer" test instance to come up. Yes, that is as expected. This is how tests are currently run, see comment 1.
(In reply to comment #23) > I can confirm that the patch fixes the problem on Cocoa ... I'll take that as a "+1" :-). Patch applied to CVS Head. Assuming this fixes immediate problem, I believe we need to switch to testing 64bit stack after 3.7 is released.
I've opened bug 354774 for the changes to the testing framework.
