Bug 433804

Description Stephan Herrmann 2014-04-29 18:31:59 EDT

This looks similar to the resolved bug 377883, but here we don't see MatchLocator in the stack but only the compiler:

Daemon Thread [Compiler Processing Task] (Suspended (exception NullPointerException))	
	ClasspathMultiDirectory(ClasspathDirectory).directoryList(String) line: 46	
	ClasspathMultiDirectory(ClasspathDirectory).doesFileExist(String, String, String) line: 75	
	ClasspathMultiDirectory(ClasspathDirectory).findClass(String, String, String) line: 96	
	NameEnvironment.findClass(String, char[]) line: 308	
	NameEnvironment.findType(char[][]) line: 326	
	LookupEnvironment.askForType(char[][]) line: 134	
	LookupEnvironment.getType(char[][]) line: 1148	
	LookupEnvironment.getResolvedType(char[][], Scope) line: 1086	
	BlockScope(Scope).getJavaLangObject() line: 2868	
	EqualExpression.resolveType(BlockScope) line: 909	
	EqualExpression(Expression).resolveTypeExpecting(BlockScope, TypeBinding) line: 1050	
	IfStatement.resolve(BlockScope) line: 269	
	Block.resolve(BlockScope) line: 119	
	IfStatement.resolve(BlockScope) line: 272	
	MethodDeclaration(AbstractMethodDeclaration).resolveStatements() line: 619	
	MethodDeclaration.resolveStatements() line: 299	
	MethodDeclaration(AbstractMethodDeclaration).resolve(ClassScope) line: 529	
	TypeDeclaration.resolve() line: 1207	
	TypeDeclaration.resolve(CompilationUnitScope) line: 1320	
	CompilationUnitDeclaration.resolve() line: 587	
	Compiler.process(CompilationUnitDeclaration, int) line: 770	
	ProcessTaskManager.run() line: 137	
	Thread.run() line: 744	

I happened to have the chance to look at this state in the debugger. If the bug follows the same pattern as bug 377883, then there must be some bogus sharing of the NameEnvironment, likely via the LookupEnvironment. In the other bug the leaking reference was a Scope, so I checked some scopes pointing ot the LookupEnvironment to find any bogus incoming path of references. But all those scopes (CUS) had only two incoming references: from the CUD and from the CS.
Unfortunately, the LE had more than 1000+ incoming references so I could not exhaustively search for a culprit.

However, when I looked for the Builder that feeds the ProcessTaskManager I could not find any, and indeed I had canceled a running build in the runtime workbench.

Indeed, if cancelling a builder lets the builder invoke the cleanup() chain before the Compiler notices the cancel, than the given NPE is well explained.

When I finally pressed resume, the NPE actually did not surface. So maybe this is all irrelevant, but now it's documented here at least :)


OTOH, we might still want to check all callers of NameEnvironment.cleanup() if they are *really* sure that no reference persists beyond the cleanup. Or: let the GC do the cleanup, but only when the NE is definitely unreferenced...??