Bug 79766 - [model] NPE in CancelableNameEnvironment
Summary: [model] NPE in CancelableNameEnvironment
Status: VERIFIED FIXED
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 M5   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 81122 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-30 07:30 EST by Dirk Baeumer CLA
Modified: 2005-02-15 06:11 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2004-11-30 07:30:09 EST 
I changed the default JDK from 1.4 for 1.5 and got the following NPE

Thread [org.eclipse.jdt.internal.ui.text.JavaReconciler] (Suspended (exception
NullPointerException))
	CancelableNameEnvironment(SearchableEnvironment).find(String, String) line: 103
	CancelableNameEnvironment(SearchableEnvironment).findType(char[], char[][])
line: 195
	CancelableNameEnvironment.findType(char[], char[][]) line: 45
	LookupEnvironment.askForType(PackageBinding, char[]) line: 116
	LookupEnvironment.getType(char[][]) line: 587
	ClassScope(Scope).getJavaLangEnum() line: 1901
	ClassScope.connectEnumSuperclass() line: 743
	ClassScope.connectSuperclass() line: 710
	ClassScope.connectTypeHierarchy() line: 852
	CompilationUnitScope.connectTypeHierarchy() line: 243
	LookupEnvironment.completeTypeBindings() line: 192
	CompilationUnitProblemFinder(Compiler).beginToCompile(ICompilationUnit[]) line: 307
	CompilationUnitProblemFinder(Compiler).resolve(CompilationUnitDeclaration,
ICompilationUnit, boolean, boolean, boolean) line: 546
	CompilationUnitProblemFinder(Compiler).resolve(ICompilationUnit, boolean,
boolean, boolean) line: 610
	CompilationUnitProblemFinder.process(CompilationUnitDeclaration,
ICompilationUnit, char[], Parser, WorkingCopyOwner, IProblemRequestor, boolean,
IProgressMonitor) line: 165
	CompilationUnitProblemFinder.process(ICompilationUnit, char[],
WorkingCopyOwner, IProblemRequestor, boolean, IProgressMonitor) line: 213
	ReconcileWorkingCopyOperation.executeOperation() line: 78
	ReconcileWorkingCopyOperation(JavaModelOperation).run(IProgressMonitor) line: 700
	ReconcileWorkingCopyOperation(JavaModelOperation).runOperation(IProgressMonitor)
line: 739
	CompilationUnit.reconcile(int, boolean, WorkingCopyOwner, IProgressMonitor)
line: 1105
	JavaReconcilingStrategy.reconcile(boolean) line: 91
	JavaReconcilingStrategy.reconcile(IRegion) line: 133
	JavaCompositeReconcilingStrategy(CompositeReconcilingStrategy).reconcile(IRegion)
line: 86
	JavaCompositeReconcilingStrategy.reconcile(IRegion) line: 96
	JavaReconciler(MonoReconciler).process(DirtyRegion) line: 75
	JavaReconciler.process(DirtyRegion) line: 318
	AbstractReconciler$BackgroundThread.run() line: 204


Variable view lools like

this= CancelableNameEnvironment  (id=26138580)
	checkAccessRestrictions= true
	monitor= NullProgressMonitor  (id=26138716)
	nameLookup= NameLookup  (id=26138724)
		packageFragmentRoots= IPackageFragmentRoot[9]  (id=26138764)
		packageFragments= HashtableOfArrayToObject  (id=26138772)
		rootToResolvedEntries= null
		timeSpentInSeekTypesInSourcePackage= 0
		unitsToLookInside= HashMap  (id=26138780)
	project= JavaProject  (id=26138732)
	searchScope= JavaSearchScope  (id=26138740)
	unitToSkip= null
Comment 1 Jerome Lanneluc CLA 2004-12-10 12:35:12 EST 
Looks like the JavaElementInfo#pathToResolvedEntries field was reset to null
while  the NameLookup was being created.
JavaProjectElementInfo#resetCaches() should be synchronized to avoid such a
scenario.
Comment 2 Jerome Lanneluc CLA 2004-12-15 08:54:43 EST 
*** Bug 81122 has been marked as a duplicate of this bug. ***
Comment 3 Jerome Lanneluc CLA 2005-01-03 06:51:11 EST 
Moved the code that creates a NameLookup to JavaProjectElementInfo#newNameLookup
and synchronized this method as well as resetCaches.
Comment 4 David Audel CLA 2005-02-15 06:11:16 EST 
Verified in I20050214-0927