Bug 124119 - [1.5][compiler] NPE recompiling in method verifier during annotation cycle detection
Summary: [1.5][compiler] NPE recompiling in method verifier during annotation cycle de...
Status: RESOLVED DUPLICATE of bug 95056
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-17 08:46 EST by Philipe Mulet CLA
Modified: 2006-01-18 12:49 EST (History)
1 user (show)

See Also:


Attachments
Intermediate patch (56.09 KB, patch)
2006-01-18 09:07 EST, Philipe Mulet CLA
no flags Details | Diff
Slightly better version of the patch (56.22 KB, patch)
2006-01-18 10:14 EST, Philipe Mulet CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2006-01-17 08:46:04 EST
JDT/Core v_633

When recompiling src libs, a NPE is detected inside method verification for type Retention. It comes across a method #value() with a null return type.

Internal compiler error
java.lang.NullPointerException

	at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.detectAnnotationCycle(ReferenceBinding.java:431)

	at org.eclipse.jdt.internal.compiler.lookup.MethodVerifier15.verify(MethodVerifier15.java:552)

	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.verifyMethods(SourceTypeBinding.java:1451)

	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.verifyMethods(CompilationUnitScope.java:743)

	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:512)

	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:332)

	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:286)

	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:251)

	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:50)

	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:214)

	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:142)

	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:593)

	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

	at org.eclipse.core.runtime.Platform.run(Platform.java:785)

	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:168)

	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:202)

	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:231)

	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

	at org.eclipse.core.runtime.Platform.run(Platform.java:785)

	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:234)

	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:253)

	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:282)

	at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:217)

	at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:182)

	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Comment 1 Philipe Mulet CLA 2006-01-17 08:55:54 EST
The null return type feels a consequence of other badness (i.e. problem occurring elsewhere prior to this point). I would expect broken bindings to have been removed, and thus not be reachable in normal cases.

Now, this scenario could be a reentrance one.
Comment 2 Philipe Mulet CLA 2006-01-17 09:33:22 EST
When debugging it, I am finding something strange. During faultInTypes of offending unit (Retention), it thinks the methods have already be resolved, and doesn't redo it, though the return type of the #value() method is still null.

public MethodBinding[] methods() {
	if ((tagBits & TagBits.AreMethodsComplete) != 0)
		return methods;
Comment 3 Philipe Mulet CLA 2006-01-17 09:35:42 EST
Looking deeper, it appears we run before into the #methods() invocation, but at a stage where the list of methods is empty (forward ref when resolving annotations). Then later on, we find the bit already set, but a method got inserted.

This is what the stack looks when first entering the #methods() call for Retention.

SourceTypeBinding.methods() line: 965
SingleMemberAnnotation(Annotation).resolveType(BlockScope) line: 243
ASTNode.resolveAnnotations(BlockScope, Annotation[], Binding) line: 491
SourceTypeBinding.getAnnotationTagBits() line: 646
SingleTypeReference(ASTNode).isTypeUseDeprecated(TypeBinding, Scope) line: 377
SingleTypeReference(TypeReference).resolveType(BlockScope, boolean) line: 134
SingleTypeReference(TypeReference).resolveType(BlockScope) line: 118
SingleMemberAnnotation(Annotation).resolveType(BlockScope) line: 229
ASTNode.resolveAnnotations(BlockScope, Annotation[], Binding) line: 491
SourceTypeBinding.getAnnotationTagBits() line: 646
SingleTypeReference(ASTNode).isTypeUseDeprecated(TypeBinding, Scope) line: 377
SingleTypeReference(TypeReference).resolveType(BlockScope, boolean) line: 134
SingleTypeReference(TypeReference).resolveType(BlockScope) line: 118
MarkerAnnotation(Annotation).resolveType(BlockScope) line: 229
ASTNode.resolveAnnotations(BlockScope, Annotation[], Binding) line: 491
SourceTypeBinding.getAnnotationTagBits() line: 646
SingleTypeReference(ASTNode).isTypeUseDeprecated(TypeBinding, Scope) line: 377
SingleTypeReference(TypeReference).resolveType(BlockScope, boolean) line: 134
SingleTypeReference(TypeReference).resolveType(BlockScope) line: 118
MarkerAnnotation(Annotation).resolveType(BlockScope) line: 229
ASTNode.resolveAnnotations(BlockScope, Annotation[], Binding) line: 491
SourceTypeBinding.getAnnotationTagBits() line: 646
QualifiedTypeReference(ASTNode).isTypeUseDeprecated(TypeBinding, Scope) line: 377
QualifiedTypeReference(TypeReference).resolveType(ClassScope) line: 157
QualifiedTypeReference(TypeReference).resolveSuperType(ClassScope) line: 107
ClassScope.findSupertype(TypeReference) line: 1106
ClassScope.connectSuperclass() line: 766
ClassScope.connectTypeHierarchy() line: 946
CompilationUnitScope.connectTypeHierarchy() line: 278
LookupEnvironment.completeTypeBindings() line: 195
Compiler.beginToCompile(ICompilationUnit[]) line: 304
Compiler.compile(ICompilationUnit[]) line: 318
BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[], SourceFile[]) line: 286
BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[]) line: 251
BatchImageBuilder.build() line: 50

Comment 4 Philipe Mulet CLA 2006-01-18 09:07:44 EST
Created attachment 33207 [details]
Intermediate patch

Moved the bound check & deprecation check to deferred stage.
However, in lookup env had to postpone the check until methods got build (if not the offending trace still occurs).

With the patch, however another NPE in lookupEnv occurs on line 190 (first stage of completeTypeBindings !?).
Comment 5 Philipe Mulet CLA 2006-01-18 10:14:57 EST
Created attachment 33213 [details]
Slightly better version of the patch
Comment 6 Frederic Fusier CLA 2006-01-18 10:38:20 EST
*** Bug 124301 has been marked as a duplicate of this bug. ***
Comment 7 Philipe Mulet CLA 2006-01-18 12:49:05 EST
Addressed differently by implementing lazy resolution for @Deprecated annotation.
See bug 95056

*** This bug has been marked as a duplicate of 95056 ***