Community
Participate
Working Groups
Doing a search (References --> Workspace) for a particular method I get an error (message and stack trace at the bottom). I do seem to get some search results, but I suspect they are incomplete. I am able to search successfully for (most) other methods in this particular class. I haven't had this problem (that I can recall) before. The class in question is in a PDE target build (i.e., it's not in my workspace). It's not practical for me to send/attach my workspace. Doing a clean and full rebuild does not fix it. Exiting and restarting the workbench does not fix it. I cannot tell you how to reproduce this, unfortunately. All I can tell you is that the method I'm looking for references to is org.eclipse.wst.common.componentcore.internal.StructureEdit.findResourcesBySourcePath(IPath, int) in WTP SDK 0.7RC3 200507290654. The offending line of code (with a little context): if (targetParameters != NoParameters) { for (int i = 0; i < targetParameters.length; i++) { ---> buffer.append(targetParameters[i].signature()); } } Since "buffer" is unconditionally set at the top of the method it must be that an element of targetParameters[] is unexpectedly null. Here's the error & stack trace: Error 2005-08-11 11:17:36.925 An internal error occurred during: "Java Search". java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.signature(MethodBinding.java:669) at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.computeUniqueKey(MethodBinding.java:322) at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.computeUniqueKey(MethodBinding.java:310) at org.eclipse.jdt.internal.compiler.lookup.Binding.computeUniqueKey(Binding.java:45) at org.eclipse.jdt.internal.core.BinaryMethod.resolved(BinaryMethod.java:328) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.newMethodReferenceMatch(MatchLocator.java:1324) at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchReportReference(MethodLocator.java:308) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1856) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2201) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2001) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1457) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:945) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:986) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1103) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:208) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:424) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:532) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:135) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:93) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) Session data: eclipse.buildId=I20050627-1435 java.version=1.4.2_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -showLocation Command-line arguments: -os win32 -ws win32 -arch x86 -data D:\Workspaces\development\7.0_3.1 -showLocation -consoleLog
It seems to be possible to end up with null inside the parameters of a method binding. Look at the method: org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding private MethodBinding resolveTypesFor(MethodBinding method) { ... } In case foundArgProblem is true, the parameters collection of the binding passed as an argument can potentially contain null values. We might want to reset that collection to NoParameters.
Gary, can you still reproduce this problem? And if so, does it still happen on the latest 3.2 nightly build?
The status of nightly build N20050928-0010 indicated some problems, so I didn't try that. But I was able to reproduce it in integration bild I20050928-1300: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.signature(MethodBinding.java:669) at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.computeUniqueKey(MethodBinding.java:322) at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.computeUniqueKey(MethodBinding.java:310) at org.eclipse.jdt.internal.compiler.lookup.Binding.computeUniqueKey(Binding.java:45) at org.eclipse.jdt.internal.core.BinaryMethod.resolved(BinaryMethod.java:328) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.newMethodReferenceMatch(MatchLocator.java:1338) at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchReportReference(MethodLocator.java:323) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:1870) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2223) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2023) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1471) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:958) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:999) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1117) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:207) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:423) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:532) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:135) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
Jerome, can you take a look at this one please.
Cannot do much without steps to reproduce. Sorry. Please reopen when you have steps.
(In reply to comment #5) > Cannot do much without steps to reproduce. Sorry. > Please reopen when you have steps. Um, well, sure you can. For example, you can dig into the code to try to find out how it is possible for an element of targetParameters[] to be null where the NPE occurs. (The stack traces I provided are proof that it *is* possible.) Olivier Thomann seems to have already done some of this and even suggested a possible fix approach (see comment #1). Have you tried to reproduce it yourself? I actually *did* provide enough information for someone to try to reproduce it (notwithstanding my remark admittedly to the contrary). It was kind of buried in my description, but it basically boils down to 1) get one of the two builds that I was able to reproduce it with and fire it up; 2) target (with PDE) an Eclipse build that also contains the referenced WTP code; 3) open class org.eclipse.wst.common.componentcore.internal.StructureEdit and select method findResourcesBySourcePath(IPath, int) in the outline; 4) do <context menu>-->References-->Workspace. Of course, whether or not the NPE occurs may well depend on the state of the workbench/workspace at the time, so those steps may or may not reproduce the problem when you try it.
(In reply to comment #6) > Um, well, sure you can. > For example, you can dig into the code to try to find out how it is possible > for an element of targetParameters[] to be null where the NPE occurs. (The > stack traces I provided are proof that it *is* possible.) Unfortunately this is not possible to protect all access for performance reasons. This is why I want to understand the exact problem you're having. > Olivier Thomann seems to > have already done some of this and even suggested a possible fix approach (see > comment #1). Kent fixed the problem highlighted by Olivier on September 28th. Unfortunately you reported that you still had the NPE. > Have you tried to reproduce it yourself? Yes but I failed to reproduce it. > I actually *did* provide enough > information for someone to try to reproduce it (notwithstanding my remark > admittedly to the contrary). I tried :-) > It was kind of buried in my description, but it > basically boils down to 1) get one of the two builds that I was able to > reproduce it with and fire it up; 2) target (with PDE) an Eclipse build that > also contains the referenced WTP code; 3) open class > org.eclipse.wst.common.componentcore.internal.StructureEdit and select method > findResourcesBySourcePath(IPath, int) in the outline; 4) do <context > menu>-->References-->Workspace. Thanks. These steps are better. I'll try those. > Of course, whether or not the NPE occurs may > well depend on the state of the workbench/workspace at the time, so those > steps may or may not reproduce the problem when you try it. This doesn't sound very encouraging. In fact I'm looking for steps that always reproduce the problem.
Here are the steps I followed: 1. Downloaded and expanded wtp-all-in-one-0.7-win32.zip 2. Started Eclipse SDK I20051102-0010 3. Changed Preferences > Plug-in Development > Target Platform to point to the directory containing WTP 0.7 4. File > Import > Plug-in Developement > External Plugins and Fragments 5. Next > Next 6. Added org.eclipse.wst.common.modulecore 7. Finish 8. Opened org.eclipse.wst.common.componentcore.internal.StructureEdit Note that it doesn't have source attached. 9. Selected findResourcesBySourcePath(IPath, int) in the Outline 10. Search for referenced in the Workspace It found one with no problem. Can you please try those steps ?
(In reply to comment #8) > ... > Can you please try those steps ? Done. I got the same results as you (i.e., it found 1 with no problem). Oh, well. So I guess this one will fade into the sunset. Anyway, thanks for your time & attention.
Please reopen if you have more details.
The sun has set...
