Comment 1 Stephan Herrmann 2015-08-10 19:06:39 EDT

I tried the steps for some minutes but never saw an NPE.

Seeing AnnotatableTypeSystem in the stack you must be using -1.8. Any other (non-standard?) preferences that could have an impact?

I'm also puzzled, how OverrideIndicatorManager and QuickAssistProcessor seem to interact here.

Comment 2 Noopur Gupta 2015-08-11 08:17:17 EDT

(In reply to Stephan Herrmann from comment #1)
> I tried the steps for some minutes but never saw an NPE.
> 
> Seeing AnnotatableTypeSystem in the stack you must be using -1.8. Any other
> (non-standard?) preferences that could have an impact?
> 
> I'm also puzzled, how OverrideIndicatorManager and QuickAssistProcessor seem
> to interact here.

I tried it again with Neon M1 and could reproduce one NPE in few attempts. I am using 1.8 and no other change in the preferences.

OverrideIndicatorManager could be called after reconciling when I open/work with the editor for the first time.

QuickAssistProcessor is invoked as we press Ctrl+1 to check for available quick assists.

Try placing caret at different locations (|if OR i|f OR if|) while pressing Ctrl+1 twice to get the list of quick assists at 'if'.

Comment 3 Noopur Gupta 2015-08-11 08:23:39 EDT

Just got a new NPE while trying it. This happened after I went to project properties > Java Compiler and clicked on Restore Defaults, OK.
And then tried the steps twice.


java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.lookup.TypeSystem.getArrayType(TypeSystem.java:252)
	at org.eclipse.jdt.internal.compiler.lookup.AnnotatableTypeSystem.getArrayType(AnnotatableTypeSystem.java:90)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromSignature(LookupEnvironment.java:1390)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:711)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:871)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:484)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:710)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:693)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:301)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:154)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:100)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:189)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1223)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getResolvedType(LookupEnvironment.java:1154)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getJavaLangString(Scope.java:2769)
	at org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveWellKnownType(DefaultBindingResolver.java:1896)
	at org.eclipse.jdt.core.dom.AST.resolveWellKnownType(AST.java:3045)
	at org.eclipse.jdt.internal.ui.text.correction.QuickAssistProcessor.getConvertStringConcatenationProposals(QuickAssistProcessor.java:1518)
	at org.eclipse.jdt.internal.ui.text.correction.QuickAssistProcessor.getAssists(QuickAssistProcessor.java:310)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeAssistCollector.safeRun(JavaCorrectionProcessor.java:409)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.run(JavaCorrectionProcessor.java:344)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.process(JavaCorrectionProcessor.java:333)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectAssists(JavaCorrectionProcessor.java:515)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectProposals(JavaCorrectionProcessor.java:291)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.computeQuickAssistProposals(JavaCorrectionProcessor.java:246)
	at org.eclipse.jface.text.quickassist.QuickAssistAssistant$ContentAssistProcessor.computeCompletionProposals(QuickAssistAssistant.java:75)
	at org.eclipse.jface.text.contentassist.ContentAssistant$5.run(ContentAssistant.java:1904)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1902)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:573)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:570)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:505)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:499)
	at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1720)
	at org.eclipse.jface.text.quickassist.QuickAssistAssistant.showPossibleQuickAssists(QuickAssistAssistant.java:128)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionAssistant.showPossibleQuickAssists(JavaCorrectionAssistant.java:198)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:192)
	at org.eclipse.ui.texteditor.TextOperationAction$1.run(TextOperationAction.java:128)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.texteditor.TextOperationAction.run(TextOperationAction.java:126)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
	at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:122)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
	at sun.reflect.GeneratedMethodAccessor38.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:252)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:286)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:507)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:558)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:378)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:324)
	at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:86)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1266)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1112)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1137)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1122)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1164)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1160)
	at org.eclipse.swt.widgets.Widget.wmKeyDown(Widget.java:1883)
	at org.eclipse.swt.widgets.Control.WM_KEYDOWN(Control.java:5035)
	at org.eclipse.swt.widgets.Canvas.WM_KEYDOWN(Canvas.java:428)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:4694)
	at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:339)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5050)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3767)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:157)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	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:669)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1515)

Comment 4 Noopur Gupta 2015-08-11 08:35:25 EDT

Here is another one that I got just now:

java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.lookup.TypeSystem.getWildcard(TypeSystem.java:368)
	at org.eclipse.jdt.internal.compiler.lookup.AnnotatableTypeSystem.getWildcard(AnnotatableTypeSystem.java:195)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1558)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1237)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1503)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:762)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:871)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:484)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:710)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:693)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:301)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:154)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:100)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:189)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:1040)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:167)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:1455)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableMethods(BinaryTypeBinding.java:368)
	at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:302)
	at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInType(Bindings.java:496)
	at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:513)
	at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethods(Bindings.java:569)
	at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethod(Bindings.java:540)
	at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager$1.visit(OverrideIndicatorManager.java:184)
	at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:611)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
	at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:470)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
	at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:212)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
	at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.updateAnnotations(OverrideIndicatorManager.java:176)
	at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.reconciled(OverrideIndicatorManager.java:258)
	at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1670)
	at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:219)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164)
	at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:112)
	at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
	at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

Comment 5 Noopur Gupta 2015-08-11 08:55:22 EDT

Created attachment 255782 [details]
Example project

I tried with a new workspace and could reproduce it easily with these steps:

- Open Eclipse Neon M1 on a new workspace and open Error Log view.
- Import attached project.
- By default, I open Eclipse with 1.7, so go to Installed JREs and add 1.8. Set it as default (check it). Click OK.
- Open the file Snippet.java and press Ctrl+1 at 'i|f' twice. Try once more.
=> I get one of the NPEs in error log.

Note that Preferences > Java > Compiler still has 1.7 as compliance level.
Even after I change that to 1.8, I can still get the NPEs with few more attempts.

Comment 6 Markus Keller 2015-08-11 10:16:03 EDT

I don't think the problem is due to an inconsistent project setup nor due to the switch from 1.7 to 1.8. It's rather a concurrency issue when the same AST is used from multiple threads. I think the issue is that the on-demand caches in TypeSystem are not thread-safe.

Everything that needs an AST in the JavaEditor uses the SharedASTProvider. Once an AST is available, various services start inspecting it in background threads (e.g. OverrideIndicatorManager) and sometimes in the UI thread (e.g. Quick Fix/Assist proposal computer on Ctrl+1).

Quick Fix/Assist proposal previews are also computed in a background thread and operate on the same AST.

It's probably hard to reproduce just by setting breakpoints, but if you look at TypeSystem.getParameterizedType(TypeSystem.java:286) or TypeSystem.getWildcard(TypeSystem.java:368), it's not hard to see that the unprotected write access to this.typeid++ from multiple threads can lead to entries in the this.types array that stay null forever.

Comment 7 Stephan Herrmann 2015-08-11 10:32:52 EDT

(In reply to Noopur Gupta from comment #5)

Thanks for the steps. I tried to follow them closely (just I don't have a "jdk1.8.0_60", where did you get that?).

Result: 0 exceptions in the log.


(In reply to Markus Keller from comment #6)
> I don't think the problem is due to an inconsistent project setup nor due to
> the switch from 1.7 to 1.8. It's rather a concurrency issue when the same
> AST is used from multiple threads. I think the issue is that the on-demand
> caches in TypeSystem are not thread-safe.

Is any part of the compiler thread-safe? I recall only one true concurrency issue where I hosed the content of a *static* field, but other than that we are coding under the assumption that the state handled by an instance of Compiler is seen only by on one thread.

If TypeSystem is now subject to concurrent access, we should probably look at code paths from JDT/UI into LookupEnvironment (of which TypeSystem is a child). Comment 4 gives a nice example.
- DOM TypeBinding holds on to the corresponding compiler BinaryTypeBinding
- BinaryTypeBinding knows its LookupEnvironment

So the entire API of LookupEnvironment is potentially subject to concurrency.
- several methods in this API cause side effects
- none of these methods has protection against race conditions

What is the (implicit) contract by which this has been working fine so far, and is starting to fail now?

Comment 8 Markus Keller 2015-08-11 10:35:53 EDT

*** Bug 449457 has been marked as a duplicate of this bug. ***

Comment 9 Stephan Herrmann 2015-08-11 10:48:42 EDT

(In reply to Stephan Herrmann from comment #7)
> Is any part of the compiler thread-safe? I recall only one true concurrency
> issue where I hosed the content of a *static* field, but other than that we
> are coding under the assumption that the state handled by an instance of
> Compiler is seen only by on one thread.

Strictly speaking the introduction of ProcessTaskManager (2008) introduced multi-threading into compilation, but here it's only a pair of threads to split the work into
- compilation proper, and
- accepting the results

These two threads don't seem to write to the same data structures.

Comment 10 Stephan Herrmann 2015-08-11 10:56:23 EDT

Additionally, I'm still puzzled what I do wrong with Noopur's repro: It never worked for me. Is this platform dependent (I'm on Linux), or dependent on hardware speed (e.g., HDD vs. SSD - I have SSD) number of cores (I have 4).

Comment 11 Stephan Herrmann 2015-08-11 10:56:51 EDT

Maybe: typing speed :)

Comment 12 Markus Keller 2015-08-11 11:06:24 EDT

(In reply to Stephan Herrmann from comment #7)
> Is any part of the compiler thread-safe?

AFAIK, neither the batch compiler nor the builder are thread-safe, since they only ever perform actual compilations in one thread.

> So the entire API of LookupEnvironment is potentially subject to concurrency.
> - several methods in this API cause side effects
> - none of these methods has protection against race conditions

I agree, the synchronization point probably needs to be quite early in the call chain.

I never even thought about this problem in the past, since I ran under the assumption that the DOM AST is completely populated as soon as client code gets their hands on it. I knew that bindings are resolved lazily, but I never made the (now obvious) connection.

The DOM AST doesn't say anything about concurrent access, and since it's not dependent on SWT and its UI thread, the general assumption is that it's thread-safe. (A bold assumption, I agree.)

> What is the (implicit) contract by which this has been working fine so far,
> and is starting to fail now?

I think it already happened in the past. Factors that could tell why it took so long to see the real problem:

- no reliable steps to reproduce and no obvious secondary problems caused by this
   => even if the problem showed up, people didn't file bugs
- machines had less cores
   => less true concurrency
- doesn't happen frequently in "normal" (non-testing) scenarios, where you typically don't invoke Quick Fix right after opening a file. I'm not sure if this problem can be reproduced at all after the OverrideIndicatorManager is done.
- maybe the increased use of parameterized types causes more potential for data races

Comment 13 Jay Arthanareeswaran 2015-08-11 11:20:29 EDT

(In reply to Noopur Gupta from comment #5)
> Created attachment 255782 [details]
> Example project

I managed to reproduce this once after several attempts. The key in my case seems to be an open hierarchy view and the exception I get is the one mentioned in comment #4.

Comment 14 Stephan Herrmann 2015-08-11 11:26:51 EDT

(In reply to Markus Keller from comment #12)
> I agree, the synchronization point probably needs to be quite early in the
> call chain.

Could we draw the boundary between DOM bindings and compiler bindings / LookupEnvironment? 

That would require us to diligently investigate all of o.e.j.core.dom.*Binding for calls into compiler internals, i.e., we would focus on all accesses to this.binding and work our way from there.

If we only need to protect against pairwise concurrency along any of these paths, than I suggest to synchronize against the LookupEnvironment instance (which, however, may only indirectly be accessible).

Also need to check: what's the role of DefaultBindingResolver? It may hold a Scope and indirectly a LookupEnvironment, too.

Comment 15 Markus Keller 2015-08-11 13:30:16 EDT

(In reply to Stephan Herrmann from comment #7)
> What is the (implicit) contract by which this has been working fine so far,
> and is starting to fail now?

This question made me think a bit more about why the OverrideIndicatorManager is running at all. Turns out it actually should not run on Ctrl+1: Filed bug 474732.

Comment 16 Markus Keller 2015-08-11 13:30:36 EDT

*** Bug 473071 has been marked as a duplicate of this bug. ***

Comment 17 Markus Keller 2015-08-11 13:30:42 EDT

*** Bug 471255 has been marked as a duplicate of this bug. ***

Comment 18 Markus Keller 2015-08-12 08:38:03 EDT

Note that bug 474732 has been pushed to master. Scenarios that involve the OverrideIndicatorManager will be harder to reproduce now, since the OverrideIndicatorManager will not run as often as before.

Comment 19 Noopur Gupta 2015-08-13 07:08:50 EDT

(In reply to Markus Keller from comment #18)
> Note that bug 474732 has been pushed to master. Scenarios that involve the
> OverrideIndicatorManager will be harder to reproduce now, since the
> OverrideIndicatorManager will not run as often as before.

With N20150812-2000, I am not able to reproduce any of the NPEs even after a good number of attempts. I will comment in case I see any NPE later.

Comment 20 Markus Keller 2015-08-13 17:47:51 EDT

OK, so it looks like the scenario that was opened by bug 181788 (3.8/4.2) has now been fixed with bug 474732.

Bug 181349 already tried to address the "parallel access to DOM AST" problem by synchronizing certain TypeBinding#get*() methods, but I'm not sure if that was really the right point of synchronization. LookupEnvironment sounds like a better candidate.

OTOH, given that we don't have a scenario to reproduce any more, we can also let this rest a bit longer.

Comment 21 Markus Keller 2015-08-17 12:32:14 EDT

*** Bug 475155 has been marked as a duplicate of this bug. ***

Comment 22 Eclipse Genie 2020-08-04 14:31:30 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 23 Eclipse Genie 2022-09-09 11:50:46 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.