Bug 21911

Summary:	NPE in the compiler
Product:	[Eclipse Project] JDT	Reporter:	Tim Francis <francis>
Component:	Core	Assignee:	Philipe Mulet <philippe_mulet>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.0
Target Milestone:	2.1 M1
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Tim Francis

2002-07-25 12:20:22 EDT

I'm seeing the following NPE in some cases in the 2.0 compiler.
It only occurs in a few scenarios, but in those cases it is
reproducible (ie, it is not timing related).  We are going to 
need to get a patch for this, if there's anything we can try 
in the short term then please provide any suggestions.

at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java
(Compiled Code))
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:917)
at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding
(SingleTypeReference.java:39)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType
(TypeReference.java:91)
at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve
(LocalDeclaration.java:134)
at 
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatement
s(AbstractMethodDeclaration.java:332)
at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements
(MethodDeclaration.java:68)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve
(AbstractMethodDeclaration.java:321)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
(TypeDeclaration.java:908)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
(TypeDeclaration.java:940)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve
(CompilationUnitDeclaration.java:235)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:533)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:337)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile
(AbstractImageBuilder.java:219)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile
(AbstractImageBuilder.java:166)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build
(BatchImageBuilder.java:50)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll
(JavaBuilder.java:170)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:99)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:392)
at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:831)
at org.eclipse.core.runtime.Platform.run(Platform.java:416)
at org.eclipse.core.internal.events.BuildManager.basicBuild
(BuildManager.java:120)
at org.eclipse.core.internal.events.BuildManager.basicBuild
(BuildManager.java:176)
at org.eclipse.core.internal.events.BuildManager.basicBuild
(BuildManager.java:186)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:146)
at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:831)
at org.eclipse.core.runtime.Platform.run(Platform.java:416)
at org.eclipse.core.internal.events.BuildManager.basicBuild
(BuildManager.java:160)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:232)
at org.eclipse.core.internal.resources.Project.build(Project.java:85)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.buildProject
(BatchExtension.java:526)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.internalJarProcess
(BatchExtension.java:473)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.runJarDeploy
(BatchExtension.java:387)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.access$100
(BatchExtension.java:102)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension$RunDeploy.run
(BatchExtension.java:232)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1361)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension$RunDeploy.execute
(BatchExtension.java:214)
at com.ibm.etools.ejbdeploy.batch.plugin.BatchExtension.run
(BatchExtension.java:177)
at com.ibm.etools.ejbdeploy.batch.impl.BatchDeploy.execute(BatchDeploy.java:141)
at com.ibm.etools.ejbdeploy.EJBDeploy.execute(EJBDeploy.java:86)
at com.ibm.etools.ejbdeploy.EJBDeploy.main(EJBDeploy.java:313)

Comment 1 Tim Francis

2002-07-25 12:21:34 EDT

Sorry, missed the top line - the problem is an NPE

java.lang.NullPointerException
        at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage
(Scope.java(Compiled Code))
        at org.eclipse.jdt.internal.compiler.lookup.Scope.getType
(Scope.java:917)
        at 
org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding
(SingleTypeReference.java:39)
...

Comment 2 Philipe Mulet

2002-07-26 06:20:14 EDT

Do you have a testcase for reproducing it ?

Comment 3 Tim Francis

2002-07-31 11:24:20 EDT

I spent some time investigating this further, trying to get more details and 
build a testcase... and I've now come to the conclulsion that it's actually a 
JDK defect.  I won't go through all the details here, but you can close this 
report, I'll be following up with the JDK team.

Comment 4 Philipe Mulet

2002-07-31 14:17:49 EDT

Do you mean that some invalid classfiles got compiled against ? Even then, our 
compiler should not crash like this. Whatever evil code we compile we must 
behave and trap errors.

There has been a number of occasions where we had to be resilient to bogus 
classfiles appearing in class libraries (from JDKs). In particular, there were 
cases where the innerclass attributes were completely wrong according to specs, 
but we have to behave anyway instead of crashing.

So I would still like a test case to add protection to our compiler.

Comment 5 Tim Francis

2002-07-31 15:39:33 EDT

I like the principle behind that answer :-)

However, in this case, I think there's really nothing you can do.  The problem 
now appears to be not just JDK, but JIT related - and it's an error in the JVM 
at runtime, it's not just bad input.  I don't think it's realistic for you to 
try and build protection against JIT defects.

Comment 6 Philipe Mulet

2002-07-31 20:18:15 EDT

Oh I see. I thought this was due to compiling against a bogus JDK class library.
Sorry for the confusion, as you said there is little we can do against hostile 
VMs...

Closing.