Community
Participate
Working Groups
I20060620-1010 and I20060627-1200, was still fine in I20060614-0843 I ran into a situation where an unbound JRE System library caused lots of scheduled bg jobs and asyncExecs during classpath initialization. I don't completely understand the problem, but I suspect it was caused by the recent rewrite of the classpath initialization code. This bug is major (or even critical) to me, since I cannot use the affected workspace any more with recent builds. Steps to reproduce: - create a Java project - in the Package Explorer, disable all filters - doubleclick .classpath, change the "con" entry to: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/xxx"/> (In my case, it was a real VM name, but I had deleted that vm from disk, so it was also unbound.) -> The workbench starts using many CPU cycles. When I open the Progress View and make it show system jobs (view menu > Preferences), I see more and more System: Open Blocked Dialog" jobs. After a while, the window becomes unresponsive and Eclipse starts to behave strange (e.g. in the Preferences dialog, I cannot switch to other pages, JRE system library editing dialog does not have any effect, ...) When I set a breakpoin on Display.asyncExec(..) while I'm in that "busy loop", I see stacktraces like the one below in the main thread. It looks like JavaProject.findPackageFragmentRoots(..) executes a SetContainerOperation, which broadcasts resource deltas. The resource deltas in turn cause refreshes in the Package Explorer, which in turn call JavaProject.findPackageFragmentRoots(..), etc., etc. ... Thread [main] (Suspended (breakpoint at line 602 in Display)) owns: RunnableLock (id=102) Display.asyncExec(Runnable) line: 602 WorkbenchActionBuilder.updateBuildActions(boolean) line: 1614 WorkbenchActionBuilder$5.resourceChanged(IResourceChangeEvent) line: 340 NotificationManager$2.run() line: 282 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 276 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastPostChange() line: 256 Workspace.endOperation(ISchedulingRule, boolean, IProgressMonitor) line: 958 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 1746 SetContainerOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 784 JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor) line: 4075 JREContainerInitializer.initialize(IPath, IJavaProject) line: 57 JavaModelManager.initializeContainer(IJavaProject, IPath) line: 1970 JavaModelManager.getClasspathContainer(IPath, IJavaProject) line: 1337 JavaCore.getClasspathContainer(IPath, IJavaProject) line: 1470 JavaProject.resolveClasspath(IClasspathEntry[]) line: 2467 JavaProject.findPackageFragmentRoots(IClasspathEntry) line: 1156 ClassPathContainer.getPackageFragmentRoots() line: 118 ClassPathContainer.getChildren(Object) line: 130 PackageExplorerContentProvider.getContainerPackageFragmentRoots(ClassPathContainer) line: 204 PackageExplorerContentProvider.getChildren(Object) line: 149 PackageExplorerContentProvider(StandardJavaElementContentProvider).hasChildren(Object) line: 221 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).isExpandable(Object) line: 1868 PackageExplorerPart$PackageExplorerProblemTreeViewer(TreeViewer).isExpandable(Object) line: 850 PackageExplorerPart$PackageExplorerProblemTreeViewer(ProblemTreeViewer).isExpandable(Object) line: 181 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).isExpandable(Item, TreePath, Object) line: 1891 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).updateChildren(Widget, Object, Object[], boolean) line: 2297 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1642 PackageExplorerPart$PackageExplorerProblemTreeViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 955 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1649 PackageExplorerPart$PackageExplorerProblemTreeViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 955 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1649 PackageExplorerPart$PackageExplorerProblemTreeViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 955 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).internalRefresh(Widget, Object, boolean, boolean) line: 1618 PackageExplorerPart$PackageExplorerProblemTreeViewer(AbstractTreeViewer).internalRefresh(Object, boolean) line: 1573 PackageExplorerPart$PackageExplorerProblemTreeViewer.internalRefresh(Object, boolean) line: 269 StructuredViewer$8.run() line: 1415 PackageExplorerPart$PackageExplorerProblemTreeViewer(StructuredViewer).preservingSelection(Runnable) line: 1323 PackageExplorerPart$PackageExplorerProblemTreeViewer.preservingSelection(Runnable) line: 409 PackageExplorerPart$PackageExplorerProblemTreeViewer(StructuredViewer).refresh(Object, boolean) line: 1413 PackageExplorerPart$PackageExplorerProblemTreeViewer(StructuredViewer).refresh(boolean) line: 1370 FilterUpdater$1.run() line: 50 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123 Display.runAsyncMessages(boolean) line: 3352 Display.readAndDispatch() line: 2998 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 1914 Workbench.runUI() line: 1878 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 419 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.run(Object) line: 95 PlatformActivator$1.run(Object) line: 78 EclipseAppLauncher.runApplication(Object) line: 92 EclipseAppLauncher.start(Object) line: 68 EclipseStarter.run(Object) line: 400 EclipseStarter.run(String[], Runnable) line: 177 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 615 Main.invokeFramework(String[], URL[]) line: 336 Main.basicRun(String[]) line: 280 Main.run(String[]) line: 977 Main.main(String[]) line: 952
Scheduled jobs were caused by an unneeded resource delta (project was touched even if the initializer didn't change the container's value). Changed SetContainerOperation#executeOperation() to handle this case. Added regression test ClasspathInitializerTests#testContainerInitializer13(). Released for 3.3 M1 in HEAD.
Verified in I20060704-0800.
I guess you meant 'verified with latest jdt.core' as the fix is not in I20060704-0800 :-)
Oops, caught me :-) I had the problem in my runtime workspace, and that one currently runs with jdt.core HEAD, not the tagged version. Anyway, I'm a happy camper again, thanks!
