Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. I created a new workspace with my team's projects (all plug-in projects) and everything works OK. 2. I install the SpringIDE 2.2.1 plugin. The installation goes OK. 3. I restart Eclipse (as recommended after plug-in installation). 4. Eclipse now sits at: Initializing Java Tooling: (1%) forever. More information: I attached the visualVM to get a thread dump. Multiple thread dumps over time always show the worker-2 running with its huge number of resolveBundles0() calls. In the attached thread dump I had tried to close some projects to see if it helped, but the related worker thread just blocked waiting on the initializing to finish.
Created attachment 123246 [details] thread dump
Created attachment 123247 [details] thread dump
We have done some work in 3.5 (contrubuted by Rob Harrop) to fix threading issues when using Spring. Can you try this on the latest 3.5 I-Build, or wait for M5 next week?
It doesn't look deadlocked, but just taking a long time. Moving to fw because this is in the resolver.
I tried 3.5m4 since the recent integration builds are all marked as failed testing. The problem was the same, so I'll test with 3.5m5 when it's available.
Created attachment 151808 [details] jprofiler trace of slow initialization I have a large workspace -- probably close to 100 projects. The strange part is that Eclipse doesn't ALWAYS hang at 1%. When it doesn't hang, initialization is done in 10-15 seconds. When it DOES hang, it can hang for a couple MINUTES. It's a very strange problem. This is a JProfiler trace of one of the slow startups.
Incidentally, I'm on OS X, so this isn't a platform-specific bug.
That trace is from Eclipse 3.5.1 Cocoa 64bit Eclipse, btw.
possibly important section on <workspace>/.metadata/.log: Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1073) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:278) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:381) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:457) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:264) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332) at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.<init>(J2EEComponentClasspathContainer.java:105) at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.install(J2EEComponentClasspathContainer.java:350) at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathInitializer.initialize(J2EEComponentClasspathInitializer.java:29) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2608) at org.eclipse.jdt.internal.core.JavaModelManager$11.run(JavaModelManager.java:2514) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2554) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1773) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2652) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2578) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2679) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1866) at org.eclipse.jdt.internal.core.JavaProject.buildStructure(JavaProject.java:424) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238) at org.eclipse.jdt.internal.core.JavaProject.getProjectCache(JavaProject.java:1835) at org.eclipse.jdt.internal.core.JavaProjectElementInfo.newNameLookup(JavaProjectElementInfo.java:309) at org.eclipse.jdt.internal.core.JavaProject.newNameLookup(JavaProject.java:2258) at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:57) at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:64) at org.eclipse.jdt.internal.core.CancelableNameEnvironment.<init>(CancelableNameEnvironment.java:26) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:158) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:243) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1242) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.initialReconcile(JavaReconcilingStrategy.java:178) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.initialReconcile(CompositeReconcilingStrategy.java:114) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:133) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:398) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173)
this bug really effects development in eclipse. it should be higher-ranked. also, it manifests itself on Ubuntu 9.10, so it is definitely not a platform-specific bug.
There are two issues here that we need to address. 1) Performing uses constraint violations during development in PDE. I think this is not necessary. Uses constraints is a runtime concept that should only surface at runtime. During compilation time I don't think it should matter if two bundles we are compiling reference different versions of a particular package. I suggest we disable uses constraint checks if the resolver is in dev mode. 2) We are supposed to have a timeout that causes the uses constraint check to break out if the algorithm has taken too long. Currently we do break out of the iteration to find the best solution, but then we try to re-resolve the current set of "resolvable" bundles. The problem is we then could find another conflict and we start over with the uses constraint checks. Once we have timed out we should stop iterating over all the solutions when re-resolving the rest of the bundles. I will look to making these two changes for M5 (although it may be too late and may be delayed to M6). CC'ing Darin and Chris to let them know this is coming. I think they have a number of bugs in PDE land that are similar.
In PDE land, bug 278486 is for disabling uses. At the moment, I don't forsee anything really bad about disabling it.
Created attachment 156572 [details] patch Here is a patch that: - disables the uses checks when in devmode. - fixes the timeout code to stop iterating over all the solutions on re-resolve once the timeout has been reached. - Allows the osgi.resolver.usesMode to be set with resolver platform properties. This will allow PDE-Build to disable the uses check if needed.
I went ahead and released the patch to get additional testing in the nightly builds and will plan to tag this fix for M5. Please pickup 3.6 M5 (when it is available) to test out your scenarios to see if they still "hang". Chris, bug 278486 is no longer needed. The patch there would not have worked because we did not read the osgi.resolver.usesMode from the platform properties you passed the resolver anyway. Now we do, but we always ignore when in dev mode.
(In reply to comment #14) > Chris, bug 278486 is no longer needed. The patch there would not have worked > because we did not read the osgi.resolver.usesMode from the platform properties > you passed the resolver anyway. Now we do, but we always ignore when in dev > mode. Do we always want to ignore it in dev mode? It seems like making it configurable wouldn't kill us and allow us the flexibility in case something happens.
(In reply to comment #15) > Do we always want to ignore it in dev mode? It seems like making it > configurable wouldn't kill us and allow us the flexibility in case something > happens. What would PDE do? Make this an option? Would you have the option set to ignore uses constraints by default? I would be fine with making it an option in the resolver instead of tying it to the dev mode option, but I prefer the user to have to do nothing in order to have it "just work" from a PDE workspace.
Thank you very much for fixing this bug. I hope that my log entry helped! Nathan Moos
any chance this could be backported to Galileo?
(In reply to comment #18) > any chance this could be backported to Galileo? We are getting late in the 3.5.2 release. I am not comfortable enough with the solution yet to recommend we backport to 3.5.x. I think we need some testing in 3.6 first to consider that. Unfortunately that makes it too late for 3.5 in my opinion. Chris, can you answer questions in comment 16? I want to lock this down this week for M5.
(In reply to comment #19) > Chris, can you answer questions in comment 16? I want to lock this down this > week for M5. I'm happy with the setting the way it is now.
*** Bug 275572 has been marked as a duplicate of this bug. ***
