Bug 98232 - [1.5][compiler] internal compiler error, but works when saved twice
Summary: [1.5][compiler] internal compiler error, but works when saved twice
Status: VERIFIED DUPLICATE of bug 97108
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 RC2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-03 01:04 EDT by Daniel Stephan CLA
Modified: 2005-06-07 10:19 EDT (History)
0 users

See Also:


Attachments
A minimal project, zipped completely. (36.32 KB, application/zip)
2005-06-03 10:53 EDT, Daniel Stephan CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Stephan CLA 2005-06-03 01:04:44 EDT
Hi folks

I get an internal compiler error with a rather long exception, like this:
Internal compiler error
java.lang.NullPointerException
	at
org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.enclosingType(ParameterizedTypeBinding.java:256)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createRawType(LookupEnvironment.java:497)
	at
org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.swapUnresolved(ParameterizedTypeBinding.java:873)
	at
org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.setResolvedType(UnresolvedReferenceBinding.java:75)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:405)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:393)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:190)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:99)
	at
org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:43)
	at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:85)
	at
org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:752)
	at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:65)
	at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:752)
	at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:568)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findExactMethod(Scope.java:789)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2159)
	at
org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:314)
	at
org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:258)
	at
org.eclipse.jdt.internal.compiler.ast.CastExpression.resolveType(CastExpression.java:380)
	at
org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:201)
	at
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:415)
	at
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:169)
	at
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:393)
	at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1063)
	at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1112)
	at
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:305)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:504)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:329)
	at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:240)
	at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:190)
	at
org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:114)
	at
org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:227)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:155)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:593)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
	at org.eclipse.core.runtime.Platform.run(Platform.java:775)
	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.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
	at org.eclipse.core.runtime.Platform.run(Platform.java:775)
	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.events.AutoBuildJob.doBuild(AutoBuildJob.java:139)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:67)

I hope this can tell you something, because I don't feel I can say much. It is
only one file this is happening on, and I have that thing already seen on 31M6
and 31M7 while I am now using RC1. I don't really know which part of the code it
doesn't like, I tried to delete stuff and see what happens, but I haven't found
the one piece of code. For example: I delete one method, and the error goes
away. But when I put the method in an isolated class, the error doesn't show. So
it seems to not be related to this method, or something in it in particular, but
rather to that method in combination with the rest of the class.

Oh, and the error manifests itself like this:
State 1: no error
Action: I change something, add a comment for example.
State 2: changed
Action: I save
State 3: saved + error
Action: I change again something, for example I add a dot and delete it
State 4: changed
Action: I save
State 5: saved and no error

State 5 wraps to State 1 again, so I have to save the file always twice now.

I hope this helps

Cheers
Daniel
Comment 1 Olivier Thomann CLA 2005-06-03 09:41:46 EDT
You should have a compilation unit with a marker that is refering to the NPE.
Could you please provide the source code of this class and its dependants to
help us to reproduce the problem?
Thanks.
Comment 2 Daniel Stephan CLA 2005-06-03 10:17:43 EDT
(In reply to comment #1)
It does show a red marker, but it puts it on the first line of the file. (The
first line is inhabited by a comment only.) When I then visit the "Problems"
view and check the entry there, it contains the shown exception stack trace.

I'll try to extract the file into a blank project without dependencies. Gimme a
minute :)
Comment 3 Olivier Thomann CLA 2005-06-03 10:41:43 EDT
The marker is on the first line because of the crash. There is no line to report
the problem as this is an internal error.
Thanks for attaching the test case.
Comment 4 Daniel Stephan CLA 2005-06-03 10:53:39 EDT
Created attachment 22324 [details]
A minimal project, zipped completely.

The class in question is this one: IndexedSparseMatrix
Comment 5 Olivier Thomann CLA 2005-06-03 15:19:42 EDT
I don't get the exact same NPE in latest.
It crashes in
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createRawType(...).

Once this is fixed, we might ask you to verify it with your test case.

Here is a simpler test case:

package test;

public class A {
	A() {
		new B().bar();
	}
}

package test;

import java.util.Map;
import java.util.Set;
import java.util.SortedSet;

public class B  {
	public Set<Map.Entry> bar() {
		return null;
	}
	void foo(SortedSet<Map.Entry> set) {
	}
}

When both are compiled at the same time, it works. But then change A and
recompile, this leads to the following stack trace.

java.lang.NullPointerException
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToRawType(LookupEnvironment.java:356)
	at
org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.enclosingType(ParameterizedTypeBinding.java:255)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createRawType(LookupEnvironment.java:569)
...

This looks like a problem with binary type binding.
Comment 6 Olivier Thomann CLA 2005-06-03 15:27:09 EDT
I confirm that using M7, I get the exact same stack trace than the original test
case using the simpler test case in comment 5.
Comment 7 Olivier Thomann CLA 2005-06-03 15:33:21 EDT
Even simpler test case:

B.java

import java.util.Map;
import java.util.Set;
import java.util.SortedSet;

public class B  {
	static Set<Map.Entry> foo(SortedSet<Map.Entry> set) {
		return null;
	}
}
--------------------------------------
A.java

public class A {
	A() {
		B.foo(null);
	}
}
Comment 8 Philipe Mulet CLA 2005-06-05 10:59:15 EDT
Added GenericTypeTest#test714
Comment 9 Philipe Mulet CLA 2005-06-05 11:01:39 EDT
Dup

*** This bug has been marked as a duplicate of 97108 ***
Comment 10 Frederic Fusier CLA 2005-06-07 10:19:28 EDT
Verified for 3.1 RC2 using build N20050607-0010 + JDT/Core HEAD