Community
Participate
Working Groups
Created attachment 127069 [details] Project directory for testcase Occurs in both: Version: 3.4.1 Build id: M20080911-1700 and: Version: 3.5.0 Build id: I20081211-1908 Steps To Reproduce: 1. Open the attached project. 2. Attempt to find references of JohnsonException in class A. More information: -- Error Details -- Date: Sat Feb 28 02:33:25 GMT 2009 Message: An internal error occurred during: "Java Search". Severity: Error Plugin: org.eclipse.core.jobs Session Data: eclipse.buildId=I20081211-1908 java.version=1.6.0_12 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86_64 Exception Stack Trace: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableMethods(BinaryTypeBinding.java:227) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:185) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1582) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1042) 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:1215) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:223) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:506) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:551) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:144) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:93) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Based on the stack this may be similar to bug 263451 and bug 250958, but neither have reproduction steps. The attached testcase is 100% reliable here. The summary of the code is.. (although, I'd recommend just looking at the attached project): 1) Custom exception class in package "foo". 2) Class which uses custom exception in doubly-nested anonymous inner class in "foo". 3) "foo" package exported as a jar. 4) Two copies of this jar (a.jar and b.jar) in the build path for another project, containing class A. Having two copies of the same jar on the classpath happens with maven.
In this case, it seems there's a problem with the jar file(s) contents. The compiler detects an invalid method signature while reading class files and so aborts the compilation abruptly leaving the 'methods' field of the BinaryTypeBinding as null. I've removed the a.jar and b.jar from the classpath, exported the source of the 'foo' folder in c.jar and d.jar files, put c.jar and d.jar files on the classpath and the search request finishes without any problem... Search engine does not prevent itself against this kind of trouble, hence facing the NPE while trying to resolve during the match locating...
(In reply to comment #1) > In this case, it seems there's a problem with the jar file(s) contents. The > compiler detects an invalid method signature while reading class files and so > aborts the compilation abruptly leaving the 'methods' field of the > BinaryTypeBinding as null. > > I've removed the a.jar and b.jar from the classpath, exported the source of the > 'foo' folder in c.jar and d.jar files, put c.jar and d.jar files on the > classpath and the search request finishes without any problem... > > Search engine does not prevent itself against this kind of trouble, hence > facing the NPE while trying to resolve during the match locating... > This is not a problem with the jar file contents. The jar files I generated included sources although they should not to reproduce the problem. So, it seems that the problem comes from the signature reader as I can see the class file contents in the Class File Editor... Here's the stack I get when the AbortCompilation occurs: TypeDeclaration.abort(int, CategorizedProblem) line: 72 ProblemReporter(ProblemHandler).handle(int, String[], int, String[], int, int, int, ReferenceContext, CompilationResult) line: 157 ProblemReporter.handle(int, String[], int, String[], int, int, int) line: 1928 ProblemReporter.handle(int, String[], String[], int, int, int) line: 1991 ProblemReporter.undefinedTypeVariableSignature(char[], ReferenceBinding) line: 6582 LookupEnvironment.getTypeFromTypeSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, char[][][]) line: 1168 LookupEnvironment.getTypeFromVariantTypeSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, ReferenceBinding, int, char[][][]) line: 1236 LookupEnvironment.getTypeArgumentsFromSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, ReferenceBinding, char[][][]) line: 1023 LookupEnvironment.getTypeFromTypeSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, char[][][]) line: 1185 BinaryTypeBinding.cachePartsFrom(IBinaryType, boolean) line: 316 LookupEnvironment.createBinaryTypeFrom(IBinaryType, PackageBinding, boolean, AccessRestriction) line: 635 LookupEnvironment.cacheBinaryType(IBinaryType, boolean, AccessRestriction) line: 172 LookupEnvironment.cacheBinaryType(IBinaryType, AccessRestriction) line: 159 MatchLocator.cacheBinaryType(IType, IBinaryType) line: 392 ClassFileMatchLocator.locateMatches(MatchLocator, ClassFile, IBinaryType) line: 179 The SignatureWrapper argument of LookupEnvironment.getTypeArgumentsFromSignature contains the following signature: Ljava/lang/Object;Lfoo/Bar<TT;>; @ 30
(In reply to comment #1) > In this case, it seems there's a problem with the jar file(s) contents. The > compiler detects an invalid method signature while reading class files and so > aborts the compilation abruptly leaving the 'methods' field of the > BinaryTypeBinding as null. This should be protected.
How the two jars were compiled ? Using the Eclipse compiler ?
(In reply to comment #4) > How the two jars were compiled ? Using the Eclipse compiler ? > I do not know for the reporter, but I generated mine using the Eclipse compiler with Export -> Jar file
The generic signature for the anonymous class is: // Signature: Ljava/lang/Object;Lfoo/Bar<TT;>; The Eclipse compiler and javac provides the same signature for the type. It looks like we try to report an undefined type variable 'T' when decoding the super interface from the anonymous type binary .class file. This looks more like a bug reading the .class file than an actual boggus signature inside the .class file itself. Kent, could you please have a look ? We might also want to make sure we don't leave methods and fields uninitialized.
Created attachment 127171 [details] test case Test case that is a zip file containing a java project with a class folder instead of jar file. The abort compilation occurs when trying to match 'T' from the anonymous to the type variable defined in the enclosing type. In this case, it should look for the enclosing method type variables and not the enclosing type.
The enclosing method can be retrieved looking at the enclosing method attribute of the enclosing type: Enclosing Method: #30 #32 foo/Bakkar.quuz()Lfoo/Bar;
*** Bug 246728 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > How the two jars were compiled ? Using the Eclipse compiler ? > The jars in the test-case were produced with export->jar, yes, but the original problem occoured with maven produced jars with: java version "1.6.0_12" Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
Created attachment 127232 [details] Proposed patch
(In reply to comment #11) > Created an attachment (id=127232) [details] > Proposed patch > Kent, I've released _testBug266582() in JavaSearchBugsTest which fails on HEAD contents with the initially described NPE but passes with your patch... You only need to remove the leading '_' to activate it when you're ready to release :-)
If the fix is simple enough, I'd like it in 3.4.x.
Created attachment 127338 [details] Proposed patch and testcase for 3.4.x
Fix and test released into 3.4.x branch (post 3.4.2)
Fix and test released for 3.5M6
Verified for 3.5M6 using I20090309-0100
