Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 When i'm searching for method-references in workspace on a specific method i get a NPE. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$2.compare(ReferenceBinding.java:48) at java.util.TimSort.countRunAndMakeAscending(TimSort.java:325) at java.util.TimSort.sort(TimSort.java:203) at java.util.Arrays.sort(Arrays.java:727) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortFields(ReferenceBinding.java:152) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:200) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:239) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1639) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1083) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1124) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1256) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Always Steps to Reproduce: 1.Rightclick on the method name 2.Select "References" 3.Then "Workspace"
Could you please provide us a reproducible test case? If not your project, a minimal test perhaps so that we can investigate? Thanks! Similar bugs in the past (bug 147875 and bug 147880) had different causes.
Can you give me a reproducible workspace? I am unable to reproduce this error. *** This bug has been marked as a duplicate of bug 362633 ***
Is it really a dup? This NPE happens in org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.FIELD_COMPARATOR.new Comparator() {...}.compare(Object, Object) while bug 362633 happens in org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.METHOD_COMPARATOR.new Comparator() {...}.compare(Object, Object)
You are right. They are different.Reopening.
Sorry, i can't give you operative code. I create a test-project, maybe i can trigger the same error too.
I've played around alot, but i couldn't reproduce this error in a testproject again.
Please let us know if you can reproduce this again. Thanks!
Though the call stacks are different, I believe the problem is same as bug 362633. I have a potential fix. I will post it shortly.
Alexander, I believe bug 362633 is similar to this one and would like to see if the patch in bug 362633 could fix your problem also. Can you please try out the latest nightly build and see if your problem is fixed.
Hi Satyam, i have tested with: Version: 3.8.0 Build id: N20120203-2000 and got the same error again. !MESSAGE An internal error occurred during: "Java Search". !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3.compare(ReferenceBinding.java:65) at java.util.TimSort.countRunAndMakeAscending(Unknown Source) at java.util.TimSort.sort(Unknown Source) at java.util.Arrays.sort(Unknown Source) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortFields(ReferenceBinding.java:169) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:208) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:242) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1639) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1083) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1124) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1256) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
(In reply to comment #10) Sigh :(. I will put in some debug statements which could help to narrow down the problem. I will update you once I release this. > Hi Satyam, > > i have tested with: > Version: 3.8.0 > Build id: N20120203-2000 > > and got the same error again. > > !MESSAGE An internal error occurred during: "Java Search". > !STACK 0 > java.lang.NullPointerException > at > org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3.compare(ReferenceBinding.java:65) > at java.util.TimSort.countRunAndMakeAscending(Unknown Source) > at java.util.TimSort.sort(Unknown Source) > at java.util.Arrays.sort(Unknown Source) > at > org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortFields(ReferenceBinding.java:169) > at > org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:208) > at > org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:242) > at > org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1639) > at > org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1083) > at > org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1124) > at > org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1256) > at > org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95) > at > org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231) > at > org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515) > at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584) > at > org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) > at > org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I am getting a similar error since updating to Indigo SR2. Version: Indigo Service Release 2 Build id: 20120216-1857 Platform: Ubuntu !ENTRY org.eclipse.core.jobs 4 2 2012-03-02 11:16:21.233 !MESSAGE An internal error occurred during: "Java Search". !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3.compare(ReferenceBinding.java:57) at java.util.TimSort.binarySort(TimSort.java:265) at java.util.TimSort.sort(TimSort.java:208) at java.util.Arrays.sort(Arrays.java:727) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortMethods(ReferenceBinding.java:159) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableMethods(BinaryTypeBinding.java:259) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:197) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1693) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1099) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1156) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1273) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:592) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:91) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Alexander and Russ, I have put in some more debug statements to track this problem in the nightly build through the new fix for bug 362633. Can you please try that out by turning some debug options and giving me the output? Here are the instructions. Create a file called .options in the eclipse folder with the following lines ###### org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/search=true ###### Then run eclipse as %eclipsec.exe -debug Please give the output of the command. Please also attach the file .metadata/.log located in your workspace. Thanks in advance.
Satyam, it was happening reliably when I added the bugnote. However, now I can no longer reproduce the issue. If/when I can I'll add a bugnote. Thanks.
Hy Satyam, we've created a new Project, where we moved all the testsources and now the NPE does not occur any more. Before we had the testsources in a folder named test/src in every project. I hope this helps to fix the problem, thanks.
(In reply to comment #15) > Hy Satyam, > we've created a new Project, where we moved all the testsources and now the NPE > does not occur any more. > Before we had the testsources in a folder named test/src in every project. > I hope this helps to fix the problem, thanks. Thanks for the info. Can you tell what your buildpath was?
I'm getting this error as well, but not just on searching -- I get it when I build my project. The stack trace is the same except the ReferenceBinding.java line number is different. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3.compare(ReferenceBinding.java:67) at java.util.TimSort.binarySort(TimSort.java:265) at java.util.TimSort.sort(TimSort.java:190) at java.util.Arrays.sort(Arrays.java:727) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortMethods(ReferenceBinding.java:169) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getMethods(BinaryTypeBinding.java:922) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getMethods(ParameterizedTypeBinding.java:596) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.getMethods(ReferenceBinding.java:883) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1327) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1298) at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2360) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:488) at org.eclipse.jdt.internal.compiler.ast.FieldDeclaration.resolve(FieldDeclaration.java:222) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1098) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1272) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:561) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:770) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:722) Eclipse version: Version: Juno Service Release 1 Build id: 20120920-0800 I then updated to the newest prod version and got the same exception on Java Build: Version: Juno Service Release 2 Build id: 20130225-0426 eclipse.buildId=M20130204-1200 java.version=1.7.0_21
Okay, updating to Kepler (Build 20130614-0229) did not fix the issue, but creating a new workspace did. So it appears something happened to the workspace to cause this issue. Note that I had been using that workspace for months with no issues until this morning. The only thing that changed was that I updated all of my Ubuntu packages, installed all updates, and restarted the computer. I normally don't restart often, so it appears to be related either to some update that got applied, or to some settings change in Eclipse that only breaks Eclipse after a restart. Note that I had a co-worker with basically the same setup do his updates and restart and his build was fine.
I traced the problem down to the Java JRE compliance level. I created a reproducible test for this issue. I copied the broken workspace to several new workspaces to test the fix. When I get the NullPointerException described above during build, I go to Window -> Preferences -> Java -> Compiler -> JDK Compliance I verify that the following settings are correctly set: Compiler compliance level: 1.7 [check] Use default compliance settings I also verify that none of my projects have project-specific settings enabled; they're all using JRE 1.7 compliance. I then go to one of the error lines in my source code, and use the Quick Fix menu to select "Chance workspace compliance to JRE 1.7". After selecting this, all the errors are gone, and the project works perfectly again. I diff'd the project settings of the workspace before and after this change, and the following 5 lines were added: $ diff workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs workspace2/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs 4a5,8 > org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7 > org.eclipse.jdt.core.compiler.compliance=1.7 > org.eclipse.jdt.core.compiler.problem.assertIdentifier=error > org.eclipse.jdt.core.compiler.problem.enumIdentifier=error 11a16 > org.eclipse.jdt.core.compiler.source=1.7 Now these are the settings I checked, and they were already set to 1.7, but that must have been a default setting that isn't defaulting correctly. My guess is that something in the build process checks the compliance version and the absence of an explicit setting causes an NPE (stacktrace above). Fix steps for others who run into this issue: Go to one of the red-underlined sections of your source code and select "Chance workspace compliance to JRE 1.7". If you can't get that to work, you could also probably add the lines above to the org.eclipse.jdt.core.prefs file manually.
(In reply to Erik B from comment #19) Thanks for your observations. Unfortunately, I don't see how this could explain the NPE. My feeling is that an exception might have interrupted the reading of a BinaryTypeBinding, hence leaving the array of methods (fields) half initialized. So, anyone seeing this exception: - do you see any previous exceptions from JDT in your logs? - please see Satyam's request for debug information in comment 13
This bug is still occuring in the newest Luna version. > please see Satyam's request for debug information in comment 13 I followed that instructions, and I may have something for you. > do you see any previous exceptions from JDT in your logs? Yep. [... 500+ "Report matching" entries... lots of possible matches] Report matching: - node set: accurate=0, possible=4 - must resolve: true (locator: true, nodeSet: true) - fine grain flags=none - node set: accurate=0, possible=0 AbortCompilation while resolving unit LoaderRepository.class org.eclipse.jdt.internal.compiler.problem.AbortCompilation: Pb(324) The type EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap cannot be resolved. It is indirectly referenced from required .class files at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:152) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:217) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2366) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:4679) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromCompoundName(LookupEnvironment.java:1201) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromConstantPoolName(LookupEnvironment.java:1231) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromConstantPoolName(LookupEnvironment.java:1239) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromSignature(LookupEnvironment.java:1309) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createFields(BinaryTypeBinding.java:547) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:473) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:696) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:214) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:201) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.cacheBinaryType(MatchLocator.java:417) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:194) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1718) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1161) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1202) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1319) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:122) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:232) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:516) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584) at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Report matching: - node set: accurate=0, possible=0 - must resolve: false (locator: true, nodeSet: true) - fine grain flags=none !ENTRY org.eclipse.jdt.ui 4 10001 2014-12-12 18:49:12.258 !MESSAGE Internal Error !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$2.compare(ReferenceBinding.java:83) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$2.compare(ReferenceBinding.java:1) at java.util.TimSort.binarySort(TimSort.java:292) at java.util.TimSort.sort(TimSort.java:217) at java.util.Arrays.sort(Arrays.java:1512) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.sortFields(ReferenceBinding.java:208) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:292) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:242) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1718) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1161) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1202) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1319) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:122) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:232) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:516) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584) at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232) at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) More informations: - I searched for method references ("Call hierarchy") in Eclipse. The same error appeared when renaming the method ("Refactor"). - The method signature was "public static void trace(String s)". - The exception occurs when parsing the class "LoaderRepository". It's org.jboss.mx.loading.LoaderRepository from jboss-jmx.jar. - This class has a reference to "EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap", which is not in the classpath (from library oswego-concurrent:concurrent:1.3.4). - Adding concurrent.jar to the classpath fixed the problem. (Alternatively, removing the jboss-jmx.jar fixed it.) The bug is hard to investigate, because: - seems to appear only in big legacy projects - seems to appear only with methods with "generic" names (many possible matches during the search) - I tried to setup a smaller project, but wasn't able to reproduce the behaviour. - The inner exception (org.eclipse.jdt.internal.compiler.problem.AbortCompilation, see below) is only sometimes logged. I neded several tries until that was visible in the logs. > My feeling is that an exception might have interrupted the reading of a BinaryTypeBinding, hence leaving the array of methods (fields) half initialized. Looks like you are right. ----- Workaround: - setup debugging as described in comment 13 - in the log, search for "AbortCompilation while resolving unit". There's a classname after that text. - find that class - check all references in that class. There must be one that is not in the current classpath - add the missing library to the classpath
Alright, if LE.getTypeFromSignature() throws AbortCompilation while we are doing createField() or createMethod() this will leave one of the arrays half-initialized indeed. We should look out for any indirect callers of BTB.cachePartsFrom() that catch the exception with insufficient cleanup, so that broken BTBs may get reused after this incident. Some candidates: - HierarchyResolver.resolve() (both variants). - SuperTypeNamesCollector.collect() - MatchLocator.process() Next BTB.availableMethods() tries to sort the array containing nulls. Boom.
Sasi, please take a look at this.
(In reply to Michael Keuchen from comment #21) > The bug is hard to investigate, because: > - seems to appear only in big legacy projects > - seems to appear only with methods with "generic" names (many possible > matches during the search) > - I tried to setup a smaller project, but wasn't able to reproduce the > behaviour. This could relate to the way how MatchLocator groups possible matches in chunks of 400. Guess: the AbortCompilation must be thrown while processing the first chunk. Then a second chunk must still exist, during which we encounter a possible match that refers to the half-initialized type from the first chunk. This could perhaps be leveraged for testing by tweaking the chunk size to some small value so that the bug is easier to trigger (or create a test with lots of dummy matches). Prior art in this field: - bug 401272 comment 18 - test case in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=730ec55536b5ef142bbace222c0f6429c2cdd532
(In reply to comment #22) > Alright, if LE.getTypeFromSignature() throws AbortCompilation while we are doing > createField() or createMethod() this will leave one of the arrays > half-initialized indeed. > > We should look out for any indirect callers of BTB.cachePartsFrom() that catch > the exception with insufficient cleanup, so that broken BTBs may get reused > after this incident. Some candidates: > - HierarchyResolver.resolve() (both variants). > - SuperTypeNamesCollector.collect() > - MatchLocator.process() > > Next BTB.availableMethods() tries to sort the array containing nulls. Boom. Couldn't we catch the AbortCompilation exception in createFields & createMethods and eliminate the unresolved methods/fields from the equation so that we never run into this situation? ClassFileMatchLocator seems to be prepared to handle the mismatch between number of available methods and number of resolved methods. Others do not seem to be interested in fields and methods in particular, only in caching the binding
(In reply to Sasikanth Bharadwaj from comment #25) > (In reply to comment #22) > > Alright, if LE.getTypeFromSignature() throws AbortCompilation while we are doing > > createField() or createMethod() this will leave one of the arrays > > half-initialized indeed. > > > > We should look out for any indirect callers of BTB.cachePartsFrom() that catch > > the exception with insufficient cleanup, so that broken BTBs may get reused > > after this incident. Some candidates: > > - HierarchyResolver.resolve() (both variants). > > - SuperTypeNamesCollector.collect() > > - MatchLocator.process() > > > > Next BTB.availableMethods() tries to sort the array containing nulls. Boom. > Couldn't we catch the AbortCompilation exception in createFields & > createMethods and eliminate the unresolved methods/fields from the equation > so that we never run into this situation? That would effectively avoid the NPE, indeed. After this cleanup, what should happen then? Proceed as if nothing happened, or rethrow the exception? (or use try-finally without catch)?
*** Bug 470934 has been marked as a duplicate of this bug. ***
*** Bug 462302 has been marked as a duplicate of this bug. ***
(In reply to Sasikanth Bharadwaj from comment #25) > Couldn't we catch the AbortCompilation exception in createFields & > createMethods and eliminate the unresolved methods/fields from the equation > so that we never run into this situation? Did you plan to draft a fix along these lines? For hints on testing see the links in comment 24.
(In reply to comment #29) > (In reply to Sasikanth Bharadwaj from comment #25) > > Couldn't we catch the AbortCompilation exception in createFields & > > createMethods and eliminate the unresolved methods/fields from the equation > > so that we never run into this situation? > > Did you plan to draft a fix along these lines? > > For hints on testing see the links in comment 24. I did create a patch, just need to find it and test it. Will take it up for 4.6
Unlikely for 4.6, didn't get to look into it, moving to 4.7
Sounds like a duplicate of Bug 489404. Note: The patch for it doesn't try to selectively catch AbortCompilation exceptions, instead it just makes sure that the methods/fields are not partially initialized - so if you think that is not good enough, you still might want to keep this open.
(In reply to Till Brychcy from comment #32) > Sounds like a duplicate of Bug 489404. very much so. > Note: The patch for it doesn't try to selectively catch AbortCompilation > exceptions, instead it just makes sure that the methods/fields are not > partially initialized - so if you think that is not good enough, you still > might want to keep this open. One more thought: maybe we should ensure that the cleanup from http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=730ec55536b5ef142bbace222c0f6429c2cdd532 happens even in case of exceptions thrown.
*** Bug 492035 has been marked as a duplicate of this bug. ***
Moving out of 4.7
Bulk move out of 4.9
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.
