Community
Participate
Working Groups
Bug_217673.test runs into OOM often: http://download.eclipse.org/eclipse/downloads/drops4/N20131016-2000/testresults/html/org.eclipse.team.tests.core_macosx.cocoa.x86_5.0.html Java heap space java.lang.OutOfMemoryError: Java heap space at org.eclipse.core.internal.events.NodeIDMap.expand(NodeIDMap.java:55) at org.eclipse.core.internal.events.NodeIDMap.put(NodeIDMap.java:170) at org.eclipse.core.internal.events.NodeIDMap.putNewPath(NodeIDMap.java:215) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:104) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeNodeIDMap(ResourceDeltaFactory.java:120) at org.eclipse.core.internal.events.ResourceDeltaFactory.computeDelta(ResourceDeltaFactory.java:64) at org.eclipse.core.internal.events.NotificationManager.getDelta(NotificationManager.java:231) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:140) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:396) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1531) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1718) at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:711) at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:647) at org.eclipse.team.tests.core.regression.Bug_217673.test(Bug_217673.java:39)
David, did you get additional info regarding the OOME?
I've increased the memory to see whether this helps. http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=f8523030fcb891524f5cf6d7cf8d6573a0cea03a
*** Bug 419841 has been marked as a duplicate of this bug. ***
I could not find any obvious memory issues on that machine by "looking at" processes running, and did find out it has 8 G total (though several "executors") thought don't think it is often that more than one are running at the same time. I've asked for more "up to date" VMs be installed ... bug 419842 ... since suspect that's where most of our committers test and end-users use (u25 or u45). Thanks,
(In reply to Dani Megert from comment #2) > I've increased the memory to see whether this helps. > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=f8523030fcb891524f5cf6d7cf8d6573a0cea03a This did not help.
(In reply to Dani Megert from comment #5) > (In reply to Dani Megert from comment #2) > > I've increased the memory to see whether this helps. > > > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > > ?id=f8523030fcb891524f5cf6d7cf8d6573a0cea03a > > This did not help. I've update the VM used to u25 (was at u10) in the slight chance it is "VM related".
(In reply to David Williams from comment #6) > (In reply to Dani Megert from comment #5) > > (In reply to Dani Megert from comment #2) > > > I've increased the memory to see whether this helps. > > > > > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > > > ?id=f8523030fcb891524f5cf6d7cf8d6573a0cea03a > > > > This did not help. > > I've update the VM used to u25 (was at u10) in the slight chance it is "VM > related". Did that update work? No tests ran on the Mac (N20131022-2000).
(In reply to Dani Megert from comment #7) > Did that update work? No tests ran on the Mac (N20131022-2000). Ah, they ran now - just took long. An I noticed that you updated the JRE after that build was done.
*** Bug 420259 has been marked as a duplicate of this bug. ***
I've disabled the test for now with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=cb50597dfd1913d552a49e7d7c7bf46b6f612725
Problem doesn't seem to be Mac-specific. The test took 1047.799s in I20131022-1300 on Windows.
(In reply to Markus Keller from comment #11) > Problem doesn't seem to be Mac-specific. The test took 1047.799s in > I20131022-1300 on Windows. Indeed! But it doesn't run into OOME and locally (Mac and Windows) it was always fast and green.
Created attachment 237467 [details] Fix The bug is just a bad choice of directory to link to: project.getFolder("test").createLink(getTempDir(), IResource.NONE, null); This has to blow up at some point once the machine has accumulated enough garbage in the shared temp directory.
Thanks Markus. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=4a0eb79d34731dab9c112665ee3fbfb2c23f4de9
(In reply to Markus Keller from comment #13) > Created attachment 237467 [details] > Fix > > The bug is just a bad choice of directory to link to: > > project.getFolder("test").createLink(getTempDir(), IResource.NONE, > null); > > This has to blow up at some point once the machine has accumulated enough > garbage in the shared temp directory. I'm not sure what you mean by "shared temp directory", (and too lazy to look at actual code right at the moment) ... but we do purposely define -Djava.io.tmpdir=${WORKSPACE}/tmp in our scripts so we don't use the machine's /tmp directory, but use one we create under Hudson's WORKSPACE (which, we clean before each run). This allows us to use java.io.File.createTempFile (...) without worrying about size or condition of system's /tmp directory. I just mention this in case it helps.
(In reply to David Williams from comment #15) > I'm not sure what you mean by "shared temp directory", (and too lazy to look > at actual code right at the moment) ... but we do purposely define > -Djava.io.tmpdir=${WORKSPACE}/tmp > I just mention this in case it helps. Yes, that's very helpful! But when I open the first 'Properties >>' link in http://download.eclipse.org/eclipse/downloads/drops4/N20131113-2000/testresults/html/org.eclipse.team.tests.core_win32.win32.x86_7.0.html , I see: Windows: java.io.tmpdir C:\Users\HUDSON~1\AppData\Local\Temp\ Mac: java.io.tmpdir /var/folders/_h/k2j3zybx5yq8xyssgt4vfns00000gp/T/ Linux: java.io.tmpdir /opt/users/hudsonbuild/workspace/ep4-unit-lin64/tmp => Looks like the tempdir is only set on Linux (where the test was indeed always quick). The released fix for this bug still makes sense for everybody running with the default tmpdir.
(In reply to Markus Keller from comment #16) > (In reply to David Williams from comment #15) > > Windows: java.io.tmpdir C:\Users\HUDSON~1\AppData\Local\Temp\ > Mac: java.io.tmpdir /var/folders/_h/k2j3zybx5yq8xyssgt4vfns00000gp/T/ > Linux: java.io.tmpdir /opt/users/hudsonbuild/workspace/ep4-unit-lin64/tmp > > => Looks like the tempdir is only set on Linux (where the test was indeed > always quick). > Thanks for this data. I've opened bug 421761 to follow-up. I know at least p2 uses it "under the covers" for some things so it'd be best to get it defined and used correctly.
Verified in N20131114-2000.