Community
Participate
Working Groups
build I20030312 - open type IHelpContextIDs - select the first content - search for references - it does nothing Log has: !ENTRY org.eclipse.ui 4 4 Mar 13, 2003 15:20:01.891 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Mar 13, 2003 15:20:01.922 !MESSAGE java.lang.NullPointerException !STACK 0 java.lang.NullPointerException at java.lang.String.<init>(String.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType (Scope.java:975) at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding (SingleTypeReference.java:39) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor (SourceTypeBinding.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor (SourceTypeBinding.java(Compiled Code)) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.fields (SourceTypeBinding.java:357) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForField sAndMethods(SourceTypeBinding.java:344) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes (CompilationUnitScope.java:352) at org.eclipse.jdt.internal.codeassist.SelectionEngine.select (SelectionEngine.java:484) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:155) at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:133) at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect (CompilationUnit.java:100) at org.eclipse.jdt.internal.ui.actions.SelectionConverter.codeResolve (SelectionConverter.java:213) at org.eclipse.jdt.internal.ui.actions.SelectionConverter.codeResolve (SelectionConverter.java:150) at org.eclipse.jdt.ui.actions.FindAction.run(FindAction.java:233) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun (SelectionDispatchAction.java:193) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run (SelectionDispatchAction.java:169) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:456) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:403) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:397) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:72) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
Are you using an IBM 1.3.1 JVM? Could you please try again without the jit? I have no problem with a VM 1.4.1.
I am using IBM 1.3.1 SR2. I've been using this VM for a while, and SR1 before that, without seeing this. However, I just tried without the JIT, and it worked normally. Tried with SR1 with the JIT on and it worked OK there too. Tried the same scenario again with SR2 with the JIT on and it failed again. So, yes, it looks like a JIT bug in IBM 1.3.1 SR2. Jeff, how do we get this reproduceable case to them?
Cannot fix it. JIT bug. Closed as WORKSFORME.
Steps to reproduce: - install eclipse build I20030312 to a new directory - my workspace in d:\eclipse\plugins is a self-hosting workspace with the org.eclipse.ui module in source, and the rest of the projects in binary - start using: eclipse -vm {JRE_DIR}\bin\java -dev bin -data d:\eclipse\plugins -update - open type org.eclipse.ui.internal.IHelpContextIds (either from the Package Explorer or using Open Type) - place the cursor in the second constant name (ADD_BOOKMARK_ACTION) - right click, Search > References > Workspace - it has no effect - .log under d:\eclipse\plugins\.metadata has the stack trace above I have zipped up my workspace and can make it available if needed.
The SR2 vm has jit problems. The UI team saw this in the TaskList at the end of the 2.0 release cycle. There is a newer JRE (SR3) however it fails as well. From the stack trace can you "prove" that it is impossible to get a null pointer exception in Scope.getTypeOrPackage()? Once you have determined which class was improperly jit'ed please retry the scenario with the jit diabled for the offending code. Here is how we disable the bad method in the TaskList: JITC_COMPILEOPT=SKIP{org/eclipse/ui/views/tasklist/TaskListContentProvider} {resourceChanged}
Reopening
I cannot reproduce following Nick's steps and running on SR3. It finds one match in AddBookMarkAction. Nick, can you reproduce on SR3?
I was not able to reproduce it with the IBM 1.3.1 SR3 SDK.
Closing as VM bug. Kevin, could you please let the JIT team know about this defect on SR2 ?
Just to document it ... I ran into this problem, still with IBM's SR2, and found using SET JITC_COMPILEOPT=SKIP{org/eclipse/jdt/internal/compiler/lookup/Scope} {getTypeOrPackage} solved (or at least bypassed) the problem. Just FYI.
Reopening for working around
*** This bug has been marked as a duplicate of 35731 ***
