Community
Participate
Working Groups
I get a StackOverflowError when I want to rename a field in large classes (about 800 lines), with smaller classes it works. The error occured in 2.1 and later. I wasn't able to reproduce the error with another project. I dint't try with another OS. My project has about 2000 classes. !SESSION Jul 21, 2003 10:36:16.288 --------------------------------------------- java.version=1.4.2 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\projekte2 -install file:C:/Programme/eclipse3.0M2/eclipse/ !ENTRY org.eclipse.ui 4 4 Jul 21, 2003 10:36:16.288 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Jul 21, 2003 10:36:16.304 !MESSAGE java.lang.StackOverflowError !STACK 0 java.lang.StackOverflowError
is this the whole stacktrace?
yes
I debuged the the latest Integration build(I20030723). I think the problem is in "org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver" in the "subTypeOfType(ReferenceBinding, ReferenceBinding)" method. I can catch the Error there.
Ralf, do you have a reproducable test case which you can attach. That would really help.
No I have not. As I said, I have a large projekt with about 2000 classes and several libs. The class I have problems with has the following Hierarchy Class1 implements Interface1, Serializable Class2 extends class1 Class3 extends class2 MyClass extends class3 with serveral other classes extending class1 and class2 and several classes extending my class. I just recognized that trying to open the Type Hierarchy fails with this Exception in the log, so perhaps the problem is because of the complex structure of that hierarchy. I'll try to reproduce it with other classes. !ENTRY org.eclipse.jdt.ui 4 10001 Aug 04, 2003 10:30:55.838 !MESSAGE Internal Error !STACK 0 java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:283) at org.eclipse.jface.window.ApplicationWindow$1.run (ApplicationWindow.java:444) at org.eclipse.swt.custom.BusyIndicator.showWhile (BusyIndicator.java:84) at org.eclipse.jface.window.ApplicationWindow.run (ApplicationWindow.java:441) at org.eclipse.ui.internal.WorkbenchWindow.run (WorkbenchWindow.java:1636) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.ensureRefreshe dTypeHierarchy(TypeHierarchyLifeCycle.java:122) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.updateInput (TypeHierarchyViewPart.java:465) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.setInputElement (TypeHierarchyViewPart.java:446) at org.eclipse.jdt.internal.ui.util.OpenTypeHierarchyUtil.openInViewPart (OpenTypeHierarchyUtil.java:94) at org.eclipse.jdt.internal.ui.util.OpenTypeHierarchyUtil.open (OpenTypeHierarchyUtil.java:75) at org.eclipse.jdt.ui.actions.OpenTypeHierarchyAction.run (OpenTypeHierarchyAction.java:175) at org.eclipse.jdt.ui.actions.OpenTypeHierarchyAction.run (OpenTypeHierarchyAction.java:141) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun (SelectionDispatchAction.java:196) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run (SelectionDispatchAction.java:172) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:542) at org.eclipse.jface.action.ActionContributionItem.access$4 (ActionContributionItem.java:496) at org.eclipse.jface.action.ActionContributionItem$6.handleEvent (ActionContributionItem.java:468) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:848) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2188) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1878) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1680) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1663) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:858) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) 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:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:291) at org.eclipse.core.launcher.Main.run(Main.java:747) at org.eclipse.core.launcher.Main.main(Main.java:583) Caused by: java.lang.StackOverflowError
Movingt o JDT/Core for comments since #3 indicates that it happens in org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver. Ralf, you mentioned that you can debug it. The debugger allows you to generate a stack trace as well (select the stack frame and simple copy it to clipboard). Can you attach the stack tract of the debugger so that we know the calling sequence that causes the failure. Thanks Dirk
Created attachment 5624 [details] StackTrace in the debugger It took me about 15 minutes of 100% CPU ;-), but here is the stack in the debugger. I inserted a try catch: private boolean subTypeOfType(ReferenceBinding subType, ReferenceBinding typeBinding) { if (typeBinding == null || subType == null) return false; if (subType == typeBinding) return true; ReferenceBinding superclass = subType.superclass(); // if (superclass != null && superclass.id == TypeIds.T_JavaLangObject && subType.isHierarchyInconsistent()) return false; if (this.subTypeOfType(superclass, typeBinding)) return true; ReferenceBinding[] superInterfaces = subType.superInterfaces(); if (superInterfaces != null) { for (int i = 0, length = superInterfaces.length; i < length; i++) { try { if (this.subTypeOfType(superInterfaces[i], typeBinding)) return true; } catch (Error e) { System.out.println("Error:"); e.printStackTrace(); throw e; } } } return false; } The stack is in the catch block.
Thanks for taking the time to produce the stack trace.
There is nothing obviously wrong in HierarchyResolver.subTypeOfType(...). Unless you can find a test case, I'm not sure what we can do. Also have you tried to increase the stack size (passing the -Xss argument to the VM)?
Yes I tried the -Xss argument with even large values, but with no effect. Could it be some kind of circular dependence of my classes or interfaces ? No idea what. I tried to find a test case, but didnt't manage to create one until now.
Thanks for the info. The only solution to debug this problem would be either a test case, or that you zip your workspace and post it somewhere I can download it.
Okay, I'll try to find a test case. Could you give me a hint to some sample Junit tests which could be useful for me ? (Create a project, classes, interfaces ...) I cant't send you my workspace, because it contains confidential classes.
I didn't expect you write code that reproduce the problem. I just expected that you would give me a set of classes (not the original ones, but classes that have been renamed with no method bodies for example), so that with this set of classes I could see the problem.
Please reopen if you have a test case.
Got a test case in e-mail. Verified this is fixed in M4. Closing.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
