Summary: | Expanding a java project with invalid classpath container entries in Project Explorer causes CPU to stay at 100% | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Raj Mandayam <ramanday> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | CC: | jshavor, laffrac, markus.kell.r, svihovec | ||||
Version: | 3.2.1 | ||||||
Target Milestone: | 3.2.2 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Raj Mandayam
2006-10-21 13:45:21 EDT
Created attachment 52463 [details]
zipped up java project
I was looking into the problem further and I have an inkling to what happened, It looks like the problem happens when the classpath entry <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v6 JRE"/> is attempted to be resolved in this code. Thread [main] (Suspended (breakpoint at line 58 in JREContainerInitializer)) JREContainerInitializer.initialize(IPath, IJavaProject) line: 57 JavaModelManager.initializeContainer(IJavaProject, IPath) line: 1900 JavaModelManager.getClasspathContainer(IPath, IJavaProject) line: 1267 JavaCore.getClasspathContainer(IPath, IJavaProject) line: 1470 JavaProject.getResolvedClasspath(IClasspathEntry[], IPath, boolean, boolean, Map) line: 2169 JavaProject.findPackageFragmentRoots(IClasspathEntry) line: 1158 ClassPathContainer.getPackageFragmentRoots() line: 118 JavaElementSorter.getPackageFragmentRoot(Object) line: 294 JavaElementSorter.compare(Viewer, Object, Object) line: 203 CommonViewerSorter.compare(Viewer, TreePath, Object, Object) line: 97 TreePathViewerSorter$1.compare(Object, Object) line: 105 ..... If you look at the method JREContainerInitializer.initialize(IPath, IJavaProject) which is in the plug-in org.eclipse.jdt.launching public void initialize(IPath containerPath, IJavaProject project) throws CoreException { int size = containerPath.segmentCount(); if (size > 0) { if (containerPath.segment(0).equals(JavaRuntime.JRE_CONTAINER)) { IVMInstall vm = resolveVM(containerPath); JREContainer container = null; if (vm != null) { container = new JREContainer(vm, containerPath); } JavaCore.setClasspathContainer(containerPath, new IJavaProject[] {project}, new IClasspathContainer[] {container}, null); } } } I found that line 52 ---> IVMInstall vm = resolveVM(containerPath); returned null for the containerPath and lines 53-58 were like JREContainer container = null; if (vm != null) { container = new JREContainer(vm, containerPath); } JavaCore.setClasspathContainer(containerPath, new IJavaProject[] {project}, new IClasspathContainer[] {container}, null); SO in line 58, we were still calling JavaCore.setClasspathContainer(containerPath, new IJavaProject[] {project}, new IClasspathContainer[] {container}, null); for a NULL container. When I put a condition like if(container != null) JavaCore.setClasspathContainer(containerPath, new IJavaProject[] {project}, new IClasspathContainer[] {container}, null); The problem went away (cpu did not stay at 100% when i expand project in project explorer). However, I do not know if this is the right fix in the given context. So, please investigate. Also it does not matter what the vmid was I changed my classpath entry to <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/blahblahJRE"/> and was able to reproduce the problem. Moving to JDT/Core for comments and to decide whether the fix for bug 160005 should be backported to 3.2.2. In N20061026-0010, I get the exception below, which indicates an error in the current fix for bug 160005. java.lang.IllegalArgumentException: Invalid classpath container implementation: getClasspathEntries() returns null. blahblah2 at org.eclipse.jdt.internal.ui.packageview.ClassPathContainer.getRequiredProjects(ClassPathContainer.java:141) at org.eclipse.jdt.internal.ui.packageview.ClassPathContainer.getChildren(ClassPathContainer.java:132) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.getContainerPackageFragmentRoots(PackageExplorerContentProvider.java:257) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider.getChildren(PackageExplorerContentProvider.java:203) at org.eclipse.jdt.ui.StandardJavaElementContentProvider.hasChildren(StandardJavaElementContentProvider.java:232) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.hasChildren(SafeDelegateTreeContentProvider.java:107) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.hasChildren(SafeDelegateTreeContentProvider.java:292) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.hasChildren(NavigatorContentServiceContentProvider.java:654) at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:1974) at org.eclipse.jface.viewers.AbstractTreeViewer.updatePlus(AbstractTreeViewer.java:2572) at org.eclipse.jface.viewers.TreeViewer.updatePlus(TreeViewer.java:993) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:798) at org.eclipse.ui.navigator.CommonViewer.createTreeItem(CommonViewer.java:150) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:775) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:749) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:794) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1301) at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:1050) at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1312) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:181) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:925) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:949) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:934) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:6442) at org.eclipse.swt.widgets.Control.wmNotify(Control.java:4221) at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1480) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:3874) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3382) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4132) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1903) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1323) at org.eclipse.swt.widgets.Tree.WM_LBUTTONDOWN(Tree.java:5321) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3363) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:4900) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4145) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1989) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3075) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1924) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1888) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:348) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:165) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:341) at org.eclipse.core.launcher.Main.basicRun(Main.java:285) at org.eclipse.core.launcher.Main.run(Main.java:987) at org.eclipse.core.launcher.Main.main(Main.java:962) Markus, can you please expand on how you're getting the exception from comment #3 ? > Markus, can you please expand on how you're getting the exception from comment > #3 ? I imported the project from attachment 52463 [details] into a clean runtime workspace and then expanded "javaProject1" in the Project Explorer (same effect as in Package Explorer). This is with I20061024-1200 or later. Re: backporting fix for bug 160005, Isn't it adding a new API ? If so, this is problematic, as no API addition may occur in a service release. We should rather provide an empty container for free in case clients forgets to initialize... unoptimal, but will address this very issue. Assumption is that this problem cannot occur on 3.3 after fix for bug 160005. Is this true ? Raj - would 3.2.2 be the right target for your needs ? Yes, I think it should be backported to Eclipse 322, Not sure what Brian's time frame is. Changed ClasspathContainerInitializer#getFailureContainer(...) to return a container that returns an empty classpath instead of null. This takes care of the problem reported in comment 3. Added regresion test ClasspathInitializerTests#testContainerInitializer15(). Still need to backport to 3.2.2. Note this was released for 3.3M4. Backport for 3.2.2 consists in changing JavaModelManager#getClasspathContainer(IPath, IJavaProject) in R3_2_maintenance stream to always return a default container (with an empty classpath) if the initializer failed to initialize the container. As a consequence, ClasspathInitiazerTests#testContainerInitializer05() has to be changed to not assume that the initializer would be called again in this case. Also testContainerInitializer14() and testContainerInitializer15() where backported to the R3_2_maintenance stream. Released for 3.2.2. Verified for 3.2.2 using build I20070112-1200. |