Bugzilla – Full Text Bug Listing
| Summary: | NPE when refreshing workspace | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Udo Walker <Udo.Walker> |
| Component: | Core | Assignee: | shankha banerjee <shankhba> |
| Status: | VERIFIED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, jarthana, manoj.palat, marcel.bruch, shankhba, srikanth_sankaran, stephan.herrmann, tparker |
| Version: | 4.2.2 | ||
| Target Milestone: | 4.5 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Udo Walker
Could you please paste the exact version of the org.eclipse.jdt.core plugin? Is this behavior reproducible? Are the projects physically stored inside the workspace directory, or are links to other locations in the filesystem involved? The Eclipse version is
eclipse.buildId=M20130204-1200
There is also this stack trace multiple times in the logs:
!ENTRY org.eclipse.jdt.ui 4 10001 2013-05-06 17:31:49.307
!MESSAGE Internal Error
!STACK 1
Java Model Exception: Java Model Status [x.y.z.standard does not exist]
at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:505)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246)
at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240)
at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240)
at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241)
at org.eclipse.jdt.internal.core.BinaryType.getClassFileInfo(BinaryType.java:229)
at org.eclipse.jdt.internal.core.BinaryType.getChildren(BinaryType.java:192)
at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:210)
at org.eclipse.jdt.internal.core.BinaryType.getMethods(BinaryType.java:460)
at org.eclipse.jdt.internal.ui.text.java.MethodProposalInfo.findMethod(MethodProposalInfo.java:152)
at org.eclipse.jdt.internal.ui.text.java.MethodProposalInfo.findMethod(MethodProposalInfo.java:94)
at org.eclipse.jdt.internal.ui.text.java.MethodProposalInfo.resolveMember(MethodProposalInfo.java:72)
at org.eclipse.jdt.internal.ui.text.java.MemberProposalInfo.getJavaElement(MemberProposalInfo.java:57)
at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.getJavaElement(AbstractJavaCompletionProposal.java:1155)
at org.eclipse.jdt.internal.ui.text.java.JavaTypeCompletionProposalComputer.computeCompletionProposals(JavaTypeCompletionProposalComputer.java:75)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:333)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:340)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:328)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:284)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1839)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:566)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:563)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:498)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:492)
at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1665)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:183)
at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:119)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76)
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:231)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:212)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:277)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:496)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:547)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:368)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:314)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:83)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100)
at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1521)
at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:4640)
at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:345)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4528)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4976)
at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2440)
at org.eclipse.swt.internal.BidiUtil.windowProc(BidiUtil.java:639)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2546)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3756)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1053)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:942)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2013-05-06 17:31:49.307
!MESSAGE x.y.z.standard does not exist
And also this one:
!ENTRY org.eclipse.recommenders.rcp.utils 4 0 2013-05-06 18:33:20.545
!MESSAGE Failed to resolve selection in '=x.y.z.standard/src\/main\/java<x.y.z.standard{___ViewImpl.java' at offset 2869
!STACK 1
Java Model Exception: Java Model Status [Index out of bounds]
at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:157)
at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:377)
at org.eclipse.jdt.internal.core.CompilationUnit.codeSelect(CompilationUnit.java:371)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromTypeRootInEditor(JavaSelectionUtils.java:147)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromEditor(JavaSelectionUtils.java:129)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionUtils.resolveJavaElementFromEditor(JavaSelectionUtils.java:112)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider.handleSelectionInEditor(JavaSelectionProvider.java:108)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider.access$1(JavaSelectionProvider.java:105)
at org.eclipse.recommenders.internal.rcp.providers.JavaSelectionProvider$1.run(JavaSelectionProvider.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
!SUBENTRY 1 org.eclipse.jdt.core 4 980 2013-05-06 18:33:20.545
!MESSAGE Index out of bounds
I think the problem disappeared when I opened the project x.y.z.standard and restarted Eclipse again.
(In reply to comment #2) > The Eclipse version is > > eclipse.buildId=M20130204-1200 > > There is also this stack trace multiple times in the logs: > > !ENTRY org.eclipse.jdt.ui 4 10001 2013-05-06 17:31:49.307 > !MESSAGE Internal Error > !STACK 1 > Java Model Exception: Java Model Status [x.y.z.standard does not exist] > at > org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement. > java:505) > at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246) > at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504) This one looks similar to the one reported in bug 403414. If you see this error again, it would be nice to hear more about this, such as what is causing the exception, settings etc. One of our users is seeing a similar stack trace: !ENTRY org.eclipse.core.resources 4 2 2013-12-19 12:55:43.125 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:121) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:201) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2176) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.rawTypeReference(ProblemReporter.java:6568) at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:160) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:208) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveTypeArgument(TypeReference.java:226) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveLeafType(ParameterizedSingleTypeReference.java:191) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:110) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:296) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:186) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1245) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces(ClassScope.java:1011) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1066) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectMemberTypes(ClassScope.java:879) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1074) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:304) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:214) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:746) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:383) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:366) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:178) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:330) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:255) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:179) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) From a stack trace it is difficult to know exactly what state the parameters to ProblemHandler.handle() are in, but the calling function can call the last parameter with a null value (ProblemReporter.handle line 2183 reads "this.referenceContext == null ? null : this.referenceContext.compilationResult())". Should the check of "referenceContext == null" in ProblemHandler.java line 132 just get moved up to avoid this NPE? I have a debuggable instance of this. I can reduce the case if needed, but here is the gist of it. In the call stack I provide:
ParameterizedSingleTypeReference is a nested class Comparator<ApiAlert>,
SingleTypeReference is ApiAlert, and ApiAlert is defined as:
public class ApiAlert<AP extends ApiParams, AF extends ApiFacts> implements Operand, GwtEnabled {...}
It seems like the attempt to report ApiAlert as a raw type is incorrect. In any case, the referenceContext member field in ProblemReporter.java is null, so ProblemHandler.handle is getting invoked with both of its last to arguments set to null.
On closer observation, the warning looks correct. It reads "ApiAlert is a raw type. References to generic type ApiAlert<AP,AF> should be parameterized". A warning marker is getting generated with this warning, but this bug is causing the compilation to fail. Just avoiding the NPE will allow the compilation to continue, but the warning will be skipped in the CompilationResult. I'm digging into the underlying error now. I found the cause of the NPE. Here is the relevant stack trace: Thread [Worker-13] (Suspended (modification of field referenceContext in ProblemReporter)) Parser.parse() line: 9755 Parser.parse(ICompilationUnit, CompilationResult, int, int) line: 9933 Parser.parse(ICompilationUnit, CompilationResult) line: 9890 Parser.dietParse(ICompilationUnit, CompilationResult) line: 8454 Compiler.accept(ICompilationUnit, AccessRestriction) line: 326 LookupEnvironment.askForType(char[][]) line: 130 UnresolvedReferenceBinding.resolve(LookupEnvironment, boolean) line: 54 BinaryTypeBinding.resolveType(TypeBinding, LookupEnvironment, boolean) line: 133 TypeVariableBinding.resolve() line: 443 BinaryTypeBinding.typeVariables() line: 1399 BinaryTypeBinding(ReferenceBinding).readableName() line: 1460 ProblemReporter.rawTypeReference(ASTNode, TypeBinding) line: 6570 What is happening is that line 9755 in Parser.java clears the ProblemReporter.referenceContext member, so when the stack unwinds, ProblemReporter's attempt to access that field generates an NPE. The comment on that line cites bug 393192 -- "// Null this so we won't escalate problems needlessly (bug 393192)". This is a fairly recent change (2013-03), which should perhaps be revisited. Terry, that's a very useful analysis! Do you have the reproducing test in a shareable fashion? Otherwise, could you please try to save and restore the previous referenceContext at beginning and end of Parser.parse()? Additionally, bug 393192 comment 4 has a list of methods assigning to referenceContext; could more methods from that list be affected, too? (In reply to Stephan Herrmann from comment #8) > Terry, that's a very useful analysis! > > Do you have the reproducing test in a shareable fashion? > Otherwise, could you please try to save and restore the previous > referenceContext at beginning and end of Parser.parse()? I have been unable to create a reduced test case. Reproduction requires that the call to ReferenceBinding.readableName() on ProblemReporter.java line 1460 is invoked on a binding that is not yet resolved, and it takes a project of a certain size (and perhaps topology) to trigger that condition. referenceContext is not being reset during the call to Parser.parse() but rather during the call to ProblemReporter.rawTypeReference(). The most local change to fix the immediate problem would be to save the referenceContext at the beginning of that function, do the ReferenceBinding.readableName() lookups that can reset the referenceContext, restore the referenceContext, and then continue with the ProblemReporter.handle() call. That fixes only one of possibly many code paths. I'm wondering if there might be a more sound fix for bug 393192, but I'm unfamiliar with that part of the code, so I'm hoping that others will chime in. > > > Additionally, bug 393192 comment 4 has a list of methods assigning to > referenceContext; could more methods from that list be affected, too? That list doesn't correspond to what I see. I count 14 assignments to ProblemReporter.referenceContext, only two of which are in Parser. My understanding is that the intent of the ProblemReporter.referenceContext field is to associate the reporting of an error or warning with a particular CompilationResult. The usage pattern appears to be that the ProblemReporter.referenceContext is set up before every possible recording of an error or warning and then discarded (I say that based on seeing referenceContext set to null at the end of 3 of the 4 ProblemReporter.handle() methods). If that is the case then perhaps protecting the resolution of all binding/type lookups by saving aside the initial referenceContext in every public ProblemReporter and using that referenceContext in the handle() methods would be sufficient. Please see Bug 442755 for a test case. They could be related. (In reply to shankha banerjee from comment #10) > Please see Bug 442755 for a test case. > > They could be related. Please ignore Comment 10. They are unrelated. (In reply to Terry Parker from comment #9) > I have been unable to create a reduced test case. Reproduction requires that > the call to ReferenceBinding.readableName() on ProblemReporter.java line > 1460 is invoked on a binding that is not yet resolved, and it takes a > project of a certain size (and perhaps topology) to trigger that condition. Basically, the problem is that while reporting a problem, in the course of that we trip into some other issue and need to report another problem, since ProblemReporter.referenceContext is not a stack, the nested diagnostic could destroy the context for the outer one. Save and restore should do the trick. Shankha, please follow up. I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=442755 too is the same underlying issue. Same as bug 442755. Note that the fix for that bug does not make ProblemReporter reentrant in the general case, but handles class path inconsistency detection and reporting while already a problem report is in flight. That is good enough for now. *** This bug has been marked as a duplicate of bug 442755 *** Verified Duplicate for Eclipse Mars 4.5 M2 Build id: I20140915-2000 |