Community
Participate
Working Groups
For a few weeks now, the Mac Hudson slave shows a dialog with a request to update the Java 7 JRE from 45 to 51. The JDKs used to run the Eclipse SDK tests are Java 7 update 25 or older on all platforms.
Markus, Can you clarify your request? The title says to update Java but your last sentence makes it sound like you need Java 7 Update 25 or older. Are you requesting an older version to be installed? or are you requesting to update to a newer update?
Sorry for being unclear. My request is to update all Java 7 versions to the latest (update 51). The main trigger for this bug was that I saw the update dialog on the Mac, and I don't like that dialog to be rendered on top of my tests. (That dialog is for the JRE that is e.g. used for Java Applets in browsers.) Then I saw that the JDKs used to run tests are also outdated on all platforms, and thought it would be good to have everything updated at once. I should have phrased that as a request, and not just a statement about the current situation.
I updated mac-tests2 to the newest Java 7. Unfortunately the older mac-tests box is too old and Java 7 isn't supported by that platform so it's still on Java 6.
Since this update, we have 2 failing tests in ui.tests that are green when run locally: junit.framework.AssertionFailedError: Multiple key down events for 'Ctrl+Space' expected:<0> but was:<1> at org.eclipse.ui.tests.keys.Bug43538Test$1.handleEvent(Bug43538Test.java:51) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) ... at org.eclipse.ui.tests.keys.Bug43538Test.testCtrlSpace(Bug43538Test.java:63) junit.framework.AssertionFailedError: Incorrect key code for 'Shift+Alt+' expected:<65536> but was:<131072> at org.eclipse.ui.tests.keys.Bug43610Test$1.handleEvent(Bug43610Test.java:48) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) ... at org.eclipse.ui.tests.keys.Bug43610Test.testShiftAlt(Bug43610Test.java:62) This screenshot should show an Eclipse workbench window, but that's not the case any more: http://download.eclipse.org/eclipse/downloads/drops4/I20140227-1100/testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.workbench.texteditor.tests.ScreenshotTest.testWindowsTaskManagerScreenshots1.png Older screenshot: http://download.eclipse.org/eclipse/downloads/drops4/I20140218-0800/testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.workbench.texteditor.tests.ScreenshotTest.testWindowsTaskManagerScreenshots1.png Thanh, could you please restart the Mac test machine?
(In reply to Markus Keller from comment #4) > Thanh, could you please restart the Mac test machine? I restarted the Mac.
Things seem worse ... since the restart. Our tests are not running at all now. And, I mean not running. Not even getting started. It installs some of the preliminary prereqs we need, and then prints _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. and then "waits there" until it times out 12 hours later. Is there some dialog that pops up asking for permission to access the network or update something?
(In reply to David Williams from comment #6) > Things seem worse ... since the restart. Our tests are not running at all > now. > > And, I mean not running. Not even getting started. It installs some of the > preliminary prereqs we need, and then prints > > _RegisterApplication(), FAILED TO establish the default connection to the > WindowServer, _CGSDefaultConnection() is NULL. > > and then "waits there" until it times out 12 hours later. > > Is there some dialog that pops up asking for permission to access the > network or update something? Sorry this is likely my fault. I looked up the error and apparently that means a daemon is running but couldn't connect to the GUI. I didn't realize I had to login to the Hudson account on the Mac after restarting it to startup the GUI. Hopefully it's fixed now but let us knwo if it's still broke.
The tests are one again running (well ... before the power problem :) But one "funny" thing was that there was a large number of tests in p2 that had to do with "could not execute (eclipse) -- permission defined". This _might_ be a problem on our end, but thought I'd ask here too, it could be a results of the "Mac setup", or "ownership of files", or something? = = = = = 0.3: java.io.IOException: Cannot run program "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0.0605513690270153/eclipse/eclipse" (in directory "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0.0605513690270153"): error=13, Permission denied junit.framework.AssertionFailedError: 0.3: java.io.IOException: Cannot run program "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0.0605513690270153/eclipse/eclipse" (in directory "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0.0605513690270153"): error=13, Permission denied = = = = = =
(In reply to David Williams from comment #8) > The tests are one again running (well ... before the power problem :) > > But one "funny" thing was that there was a large number of tests in p2 that > had to do with "could not execute (eclipse) -- permission defined". This > _might_ be a problem on our end, but thought I'd ask here too, it could be a > results of the "Mac setup", or "ownership of files", or something? > > = = = = = > 0.3: java.io.IOException: Cannot run program > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153/eclipse/eclipse" (in directory > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153"): error=13, Permission denied > > junit.framework.AssertionFailedError: 0.3: java.io.IOException: Cannot run > program > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153/eclipse/eclipse" (in directory > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153"): error=13, Permission denied > = = = = = = Not sure but looking at the directory I don't see the file it's listing. So maybe the "Permission denied" is actually "File not found"? Anyway double checked the permissions and hudsonBuild owns all the files so things appear to be normal.
(In reply to David Williams from comment #8) > The tests are one again running (well ... before the power problem :) > > But one "funny" thing was that there was a large number of tests in p2 that > had to do with "could not execute (eclipse) -- permission defined". This > _might_ be a problem on our end, but thought I'd ask here too, it could be a > results of the "Mac setup", or "ownership of files", or something? > > = = = = = > 0.3: java.io.IOException: Cannot run program > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153/eclipse/eclipse" (in directory > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153"): error=13, Permission denied > > junit.framework.AssertionFailedError: 0.3: java.io.IOException: Cannot run > program > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153/eclipse/eclipse" (in directory > "/Users/hudsonBuild/workspace/ep4-unit-mac64/tmp/1393824210551-0. > 0605513690270153"): error=13, Permission denied > = = = = = = This is a problem if you download the build for Mac and run locally as well. I see this link for the eclipse in the root folder: eclipse -> Eclipse.app/Contents/MacOS/eclipse But this is the file it links to: ls -l Eclipse.app/Contents/MacOS/ total 312 -rw-r--r--@ 1 watson staff 87296 Mar 2 21:12 Eclipse Which uses uppercase Eclipse and is not executable. I cannot launch eclipse with build I20140302-2000 until I change the executable bits for Eclipse. I did not have not have to rename to lower case since MacOS will ignore case here.
(In reply to Thomas Watson from comment #10) Thanks for helping to diagnose, Tom. I've opened bug 429485 to track the p2/mac problem. I _think_ this bug is fixed, since I think original issue (and side effect) is fixed ... but will let Markus decide that ... since I've only skim read original issue.
(In reply to Thanh Ha from comment #7) Now (I20140302-2000) we're back to the state before comment 4: Most tests are running fine, but the two ui.tests fail again and the screenshot doesn't show the Eclipse workbench window: http://download.eclipse.org/eclipse/downloads/drops4/I20140302-2000/testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.workbench.texteditor.tests.ScreenshotTest.testWindowsTaskManagerScreenshots1.png I don't even see the Eclipse.app that's running the tests in the dock. That one used to be visible (along with the workbench window).
(In reply to Markus Keller from comment #12) > (In reply to Thanh Ha from comment #7) > Now (I20140302-2000) we're back to the state before comment 4: Most tests > are running fine, but the two ui.tests fail again and the screenshot doesn't > show the Eclipse workbench window: > http://download.eclipse.org/eclipse/downloads/drops4/I20140302-2000/ > testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.workbench.texteditor.tests. > ScreenshotTest.testWindowsTaskManagerScreenshots1.png > > I don't even see the Eclipse.app that's running the tests in the dock. That > one used to be visible (along with the workbench window). Sorry maybe a dumb question as I'm not familiar with how you perform the screenshot. Is it possible that the screenshot is taken after the test has already run? Maybe the tests are running faster than expected?
The "missing dock" icon _might_ be related, indirectly, to the issues causing bug 429228.
(In reply to Thanh Ha from comment #13) > Sorry maybe a dumb question as I'm not familiar with how you perform the > screenshot. Is it possible that the screenshot is taken after the test has > already run? Maybe the tests are running faster than expected? No, we're using the SWT API GC#copyArea(Image, int, int), which runs and completes while the workbench window is up. I've added more logging to get the shell/display bounds: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=ce8cdb5940f1e8f59d314868ad6d1676979db605 (In reply to David Williams from comment #14) > The "missing dock" icon _might_ be related, indirectly, to the issues > causing bug 429228. Can't be ruled out, but is IMO unlikely: The workbench window and dock icon were already missing in I20140225-0800, where I don't yet see the branding issues.
In I20140303-2000, the screenshot still doesn't show the workbench window and Eclipse app in the dock, but the bounds look fine (window has display bounds minus menu bar): Shell {Java - Eclipse SDK} @ Rectangle {0, 22, 800, 521} Display @ Rectangle {0, 0, 800, 600} Another difference I saw is that the menu bar is transparent now, but it was opaque before the restart. Matt/Denis: Is there a special login procedure for the Hudson User on the Mac? (In reply to Markus Keller from comment #4) > Since this update, we have 2 failing tests in ui.tests that are green when > run locally: > ... > at org.eclipse.ui.tests.keys.Bug43538Test.testCtrlSpace(Bug43538Test.java:63) > ... > at org.eclipse.ui.tests.keys.Bug43610Test.testShiftAlt(Bug43610Test.java:62) These test failures are due to bug 429592. It's either a coincidence that they started to fail now (e.g. because of a Platform UI fix that sets an initial focus), or it's just a side-effect of the missing workbench window.
(In reply to Markus Keller from comment #16) > > Matt/Denis: Is there a special login procedure for the Hudson User on the > Mac? Not that I recall. If I connect to mactests2 I can see that the Hudson user is shown as being logged in. -M.
Hmm, Markus did you mean I should update the JRE we use in our tests, too? I just realized we are still using /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre I assume newest one is at /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre Thanh, have you (or, should we) define a symbolic link, like we do on build machine ... to point to "latest"? If you have, I don't think I've used it in Mac tests. I guess we'd be out of luck on Windows? (and always have to "hard code"?)
(In reply to David Williams from comment #18) > Hmm, Markus did you mean I should update the JRE we use in our tests, too? > > I just realized we are still using > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre > > I assume newest one is at > /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre > > Thanh, have you (or, should we) define a symbolic link, like we do on build > machine ... to point to "latest"? > No I don't create the symlinks on the Mac since we use the package manager to install the JDK. I actually thought it deleted the old versions when it upgraded but maybe I'm wrong? > If you have, I don't think I've used it in Mac tests. > > I guess we'd be out of luck on Windows? (and always have to "hard code"?) As far as I'm aware but maybe I'm wrong, Windows doesn't do symlinks in the same way Unix systems do so we might be out of luck here.
(In reply to Thanh Ha from comment #19) > No I don't create the symlinks on the Mac since we use the package manager > to install the JDK. I actually thought it deleted the old versions when it > upgraded but maybe I'm wrong? AFAIK, Oracle JDK installers never remove old versions -- they just leave the old ones alone, add the new one, and register it as default for /usr/bin/java and /usr/libexec/java_home . Note that the system JRE that's used e.g. for browser applets is completely separate from developer JDKs. The JRE popped up the dialog, and that's the one you see in System Preferences > Java Control Panel. But a JRE is not enough for our builds, since it misses some tools (e.g. Javadoc). I have never seen a dialog asking me for a JDK update on the Mac. These have to be downloaded and installed manually.
I've opened bug 429926 to update all Hudson instances with JDK 1.7.0_51 ... not for the same reason as this bug, but in order to better test/support bug 416870. Just to emphasize what Markus has already said, we definitely want to keep (most) old versions around, since in the ideal, we'll soon be testing against multiple versions. And, to emphasize the other part of what he said, when we ask for "java to be installed" ... we are not talking about the type installed via the browser ... guess that doesn't hurt :) ... but, we need full versions directly accessible Lastly, I suppose on Windows, "we" could establish the convention that JAVA_HOME ... as defined in "Hudson setup" is set to "latest" (I'd avoid setting it for the whole machine ... unless you find you just have to ... same for classpath ... it should not be defined globally ... unless you find you need to, for some reason. I noticed on the Widows machine that under the 'java' directory, following versions appear installed: jdk1.5.0_22 jdk1.6.0_20 jdk1.6.0_30 jdk1.7.0_07 jdk7u2 jre1.5.0_22 jre6 jre6u30 jre7 jre7u7 But, "JAVA_HOME" was "pointing to" the older jdk1.6.0_20
FWIW, I don't see "51" in the usual spot where we get our VMs from /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/bin/java /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java
(In reply to David Williams from comment #22) > FWIW, I don't see "51" in the usual spot where we get our VMs from > > /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/bin/java > /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/bin/java > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java > /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java > /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java So when I did the update last time I used the Java updater that was in the Mac's system tools. When I double checked the updater app today it said that "51" was installed and is the latest. So I'm not sure where it installed "51" to. I decided to try download the JDK DMG file from Oracle's site and installed that and I can now see the new "51" version in the list in /Library/Java/JavaVirtualMachines. Hope this helps.
(In reply to Thanh Ha from comment #23) > So when I did the update last time I used the Java updater that was in the > Mac's system tools. When I double checked the updater app today it said that > "51" was installed and is the latest. So I'm not sure where it installed > "51" to. The System Preferences > Java Control Panel shows the JRE. That's the one you updated first (and which showed the update dialog). It's located in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java > I decided to try download the JDK DMG file from Oracle's site and installed > that and I can now see the new "51" version in the list in > /Library/Java/JavaVirtualMachines. > > Hope this helps. Yes, that should be the Mac part of the fix for bug 429926. Thanh, did you do something else to the machine or hudson user? The screenshot works again, and I would be very interested to know what fixed that problem. It's probably not the jdk1.7.0_51.jdk, since the tests still ran with 45. http://download.eclipse.org/eclipse/downloads/drops4/N20140310-2000/testresults/macosx.cocoa.x86_5.0/org.eclipse.ui.workbench.texteditor.tests.ScreenshotTest.testScreenshot.png The old Eclipse icon in the dock is very likely a Mac OS X bug. They cache app icons and only refresh their caches randomly.
(In reply to Markus Keller from comment #24) > (In reply to Thanh Ha from comment #23) > > So when I did the update last time I used the Java updater that was in the > > Mac's system tools. When I double checked the updater app today it said that > > "51" was installed and is the latest. So I'm not sure where it installed > > "51" to. > > The System Preferences > Java Control Panel shows the JRE. That's the one > you updated first (and which showed the update dialog). It's located in > /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java > Oh that explains it. Thanks, I was not aware this was for the JRE and not the JDK. (In reply to Markus Keller from comment #24) > Thanh, did you do something else to the machine or hudson user? The > screenshot works again, and I would be very interested to know what fixed > that problem. It's probably not the jdk1.7.0_51.jdk, since the tests still > ran with 45. > No I did not touch anything else other than installing the JDK with the DMG file I downloaded from Oracle's site.
