Community
Participate
Working Groups
Using eclipse.buildId=I20080327-0100 java.version=1.6.0_05 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_CA Framework arguments: D:\eclipse\sdk\eclipse\org.eclipse.platform -showlocation Command-line arguments: -os win32 -ws win32 -arch x86 D:\eclipse\sdk\eclipse\org.eclipse.platform -consolelog -console -showlocation I got this failure by doing Ctrl + Shift + G on a field reference. java.lang.NullPointerException at org.eclipse.jdt.internal.core.search.matching.MatchLocator.createHandle(MatchLocator.java:574) at org.eclipse.jdt.internal.core.search.matching.MemberDeclarationVisitor.storeHandle(MemberDeclarationVisitor.java:138) at org.eclipse.jdt.internal.core.search.matching.MemberDeclarationVisitor.visit(MemberDeclarationVisitor.java:229) at org.eclipse.jdt.internal.compiler.ast.SingleNameReference.traverse(SingleNameReference.java:901) at org.eclipse.jdt.internal.compiler.ast.ConditionalExpression.traverse(ConditionalExpression.java:502) at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.traverse(LocalDeclaration.java:245) at org.eclipse.jdt.internal.compiler.ast.SwitchStatement.traverse(SwitchStatement.java:380) at org.eclipse.jdt.internal.compiler.ast.Block.traverse(Block.java:127) at org.eclipse.jdt.internal.compiler.ast.TryStatement.traverse(TryStatement.java:853) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:239) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2133) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2583) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2312) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1604) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1036) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1077) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1209) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:217) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:500) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:550) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:143) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
I am investigating with my workspace since I cannot extract a simple test case.
I could not reproduce on the next restart. So since I was not running in self-hosting, I have no way to find out what was wrong.
Set back to normal as I cannot reproduce anymore once I restarted my workspace. However there is a potential NPE in the calls on that line.
*** Bug 224645 has been marked as a duplicate of this bug. ***
Paul, Did you have compiler errors in your workspace? Did search stop to work after this NPE? Can you reproduce it easily?
Although I cannot reproduce while searching for references to System.err in an Eclipse full-source workspace, I think it could be good to make the code safe and check if the resolved type is null in MatchLocator.createHandle(AbstractVariableDeclaration, IJavaElement) method...
Created attachment 93998 [details] Proposed patch
(In reply to comment #5) > Paul, > Did you have compiler errors in your workspace? No, the workspace just has a lot of warnings. Specifically, I have platform-ui, platform-ui-examples and platform-ui-tests checked out from HEAD, with ui.carbon and ui.win32 closed. > Did search stop to work after this NPE? Yes, it stopped the search. > Can you reproduce it easily? I restarted my workbench and was able to reproduce it using the same System.err steps. PW
Olivier helped me to reproduce the problem and hopefully we can verified that the patch really fixes the problem. However, depending on further investigations, I might open a new bug for M7 to tune the fix if I can precisely understand why this binding is null in this case. Then the fix would be on the origin of the problem instead of its symptom only... Released for 3.4M6 in HEAD stream.
Paul problem is identical. The resolveType is null, because the match is inside a binary method with source attached, but the method's statements are not resolved. So a null check will fix this problem, but I am not convinced that we should get that far in this case. The method's statement should be resolved or we should not try to locate a match inside the method.
And just before I forget, my NPE was while searching: local declaration: boolean succeed = new Main(new PrintWriter(new OutputStreamWriter(out)), new PrintWriter(new OutputStreamWriter(err)), true, null, null).compile(arguments); class: public class org.eclipse.jdt.internal.compiler.tool.EclipseCompiler method: public int run(InputStream in, OutputStream out, OutputStream err, String... arguments) { PW
Verified for 3.4M6 using I20080328-1410.
