Community
Participate
Working Groups
Build Identifier: 20100617-1415 running eclipse Helios 3.6 (64 bit) on Mac OS X (10.6.8). java -version: java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) GWT plugin, 2.4, installed. On start up the 'initializing java tooling: 30%' status displays for about a minute if VPN (Cisco anyconnect) is running. < 2 seconds (or not at all) without VPN running. Also, can get the SBOD (spinning beachball of death) if I have a GWT project with a run or debug configuration and try to edit it (or create one). Locks up the launch config dialog. This happens with only one project in workspace (or more). This happens with or without the split tunnel setup (multi-home). Happens with Indigo or Helios, 32 bit or 64 bit. Reproducible: Always Steps to Reproduce: 1. Start the cisco VPN Anyconnect client 2. Start eclipse 3. Watch the 'initialzing java tooling' status for about a minute. 4. Try creating a new Debug configuration for a GWT project. 5. Watch the SBOD for about 20 minutes.
Can you get a stack dump when it hangs?
Stack traces attached. Taken in order, about 5 seconds apart during hang, starting with stack-trace.1 through stack-trace.5.
Created attachment 209410 [details] Stack Trace 1
Created attachment 209411 [details] Stack Trace 2
Created attachment 209412 [details] Stack Trace 3
Created attachment 209413 [details] Stack Trace 4
Created attachment 209414 [details] Stack Trace 5
Thanks, this seems to be the culprit: "Worker-4" prio=5 tid=11e436800 nid=0x121d10000 runnable [121d0f000] java.lang.Thread.State: RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) at java.io.File.isFile(File.java:778) at org.eclipse.jdt.internal.launching.macosx.MacOSXVMInstallType.getDefaultSystemLibrarySource(MacOSXVMInstallType.java:189) at org.eclipse.jdt.internal.launching.StandardVMType.getDefaultLibraryLocations(StandardVMType.java:310) at org.eclipse.jdt.launching.JavaRuntime.getLibraryLocations(JavaRuntime.java:1639) at org.eclipse.jdt.internal.launching.JREContainer.computeClasspathEntries(JREContainer.java:293) at org.eclipse.jdt.internal.launching.JREContainer.getClasspathEntries(JREContainer.java:267) at org.eclipse.jdt.internal.launching.JREContainer.getClasspathEntries(JREContainer.java:371) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2651) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2783) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1915) at org.eclipse.jdt.core.JavaCore.initializeAfterLoad(JavaCore.java:3496) at org.eclipse.jdt.internal.ui.InitializeAfterLoadJob$RealJob.run(InitializeAfterLoadJob.java:35) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Searching bugzilla for getBooleanAttributes0 yields a number of bugs with similar stack traces, e.g.: bug 312038, bug 338251, bug 336302, bug 312959. In some of these bugs things have been improved by avoiding file access through caching. However, the bottom line seems to be that file system access is just unbearably slow, be it remotely mounted or huge or what ever. Could you please check whether toggling your VPN affects access to any part of your file system? In particular check any location where we might look for sources of your JRE.
not sure what I should be looking for at this point.
(In reply to comment #9) > not sure what I should be looking for at this point. My impression is that this bug is not a misbehavior of the JDT but an issue between your VM and your file system. I was hoping that either you can verify that other ways to access the file system show a similar delay or from reading through those other bugs with the same symptom you would get a better understanding of the root cause and/or hints how to work around. I'm reassigning to JDT/Debug (who own the jdt.launching implementation) - perhaps they can give more advice.
OK.. bug 312038 provided me with some very helpful insight. Especially this: ************************ "I have found out what the problem is. The code which is looking for src.jar and src.zip is not finding the file as eclipse is looking in the following directory. /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home But the src.jar is in the new location. /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/src.jar I copied the src.jar file into the old location and now it works. I found this out as it was also hanging when I went into the Preferences to look at the installed JRE's and it was hanging there. I then did a thread dump and looked for the source code which told me it was looking for the src.jar or src.zip file." ************************ I was able to also copy my src.jar from new install to old location and problem disappeared. Now I'm trying to figure out how it got messed up. I had very recently run a Mac OS X update which DID update the JVM and I suspect that Eclipse just somehow did not find the new src.jar location. Any insight to that would be appreciated.
this was also interesting: http://stackoverflow.com/questions/6614380/jdk-on-osx-10-7-lion
(In reply to comment #12) > this was also interesting: > http://stackoverflow.com/questions/6614380/jdk-on-osx-10-7-lion The problem comes from our jdt.launching.macosx bundle. In the VM type we have search cues for where to find the JRE / SDK installs. These cues have not been updated to support the new location of snow leopard / lion, so we end up following links and searching pretty much the whole HD. See org.eclipse.jdt.internal.launching.macosx.MacOSXVMInstallType#getDefaultJavadocLocation for more info.
> (In reply to comment #12) > The problem comes from our jdt.launching.macosx bundle. There is a bit deeper problem here. During an upgrade the old VM is moved to the new location, but in Eclipse you have a JRE defined that references the old location, so when we try to resolve the JRE we fail (causing delays, etc). Even if we did update the search cues it would not help us to know where the VM Eclipse used to reference has moved to. In this case we should be doing a better job of ignoring the VM if it has completely moved - but I am guessing the link for the VM is remaining but the actual guts have been removed. As I see it there is really two workarounds for this: 1. copy the source jar back to the old location 2. go to the Installed JREs page and remove the old JRE and hit the search button to find the new one. We should update our JRE resolution code to ignore this and remove 'moved' VMs (I am surprised we don't already) Fixing this could have an effect on how we re-resolve JREs for Mac (or in general), so I am going to defer this until 4.3 so we can spend more time on it (and not risk breaking M7).
P1 priority means we will not ship Juno without it. Since it is already targetted to 4.3/Kepler I will move to P2 priority.
Just to cross reference, see bug 392434 for similar (but less complicated) issue.
Created attachment 227141 [details] work in progress This patch updates the library location source / library info resolution to rely on the new locations.
Pushed patch + updates to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=deac7a650c763324df6eaf51ef88d4d23a88d0d9 The fix adds some bounds for searching and makes sure to check for src.jar and src.zip. It is still clunky though, and could be made a lot faster if we cached the locations for the default libraries (see bug 401432) - reason being, that when you add the JRE / JDK or when you start Eclipse these source locations are re-computed for each default library, one at a time.
