Bug 36854 - NPE opening type hierarchy
Summary: NPE opening type hierarchy
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.0 M2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 37804 38163 38688 39200 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-04-24 13:01 EDT by Darin Swanson CLA
Modified: 2003-07-17 06:16 EDT (History)
5 users (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 Darin Swanson CLA 2003-04-24 13:01:37 EDT 
Build 20030422
java.runtime.version=1.4.2-beta-b19

I had used the Open type dialog to open AbstractLaunchConfigurationTab.
Selecting the type name, I hit F4.
Hitting F4 again..no problem

Caused by: java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.convert
(SourceTypeConverter.java:117)
at 
org.eclipse.jdt.internal.compiler.parser.SourceTypeConverter.buildCompilationUni
t(SourceTypeConverter.java:77)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept
(HierarchyResolver.java:168)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType
(LookupEnvironment.java:106)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage
(PackageBinding.java:173)
at 
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findOnDemandImport
(CompilationUnitScope.java:363)
at 
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleTypeImpo
rt(CompilationUnitScope.java:422)
at 
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleTypeI
mport(CompilationUnitScope.java:532)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage
(Scope.java:1310)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype
(ClassScope.java:789)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass
(ClassScope.java:582)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy
(ClassScope.java:675)
at 
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarc
hy(CompilationUnitScope.java:252)
at 
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings
(LookupEnvironment.java:221)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve
(HierarchyResolver.java:498)
at 
org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProje
ct(IndexBasedHierarchyBuilder.java:229)
at 
org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPote
ntialSubtypes(IndexBasedHierarchyBuilder.java:340)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build
(IndexBasedHierarchyBuilder.java:165)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute
(TypeHierarchy.java:322)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh
(TypeHierarchy.java:1368)
at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation
(CreateTypeHierarchyOperation.java:78)
at org.eclipse.jdt.internal.core.JavaModelOperation.execute
(JavaModelOperation.java:365)
at org.eclipse.jdt.internal.core.JavaModelOperation.run
(JavaModelOperation.java:704)
at org.eclipse.jdt.internal.core.JavaElement.runOperation(JavaElement.java:540)
at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy
(SourceType.java:370)
at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy
(SourceType.java:359)
at 
org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefr
esh(TypeHierarchyLifeCycle.java:141)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.access$0
(TypeHierarchyLifeCycle.java:127)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle$1.run
(TypeHierarchyLifeCycle.java:115)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:101)
Comment 1 Olivier Thomann CLA 2003-04-24 16:07:35 EDT 
I could not reproduce. Do you get it all the time?
Comment 2 Olivier Thomann CLA 2003-04-24 16:17:57 EDT 
Add CC'
Comment 3 Darin Swanson CLA 2003-04-24 16:21:40 EDT 
It does not occur all the time...and I have not been able to reproduce it on 
the same type twice.
Comment 4 Philipe Mulet CLA 2003-04-25 05:09:40 EDT 
Offending code line is:

	this.unit.types = new TypeDeclaration[typeCount];

where a couple lines above, units is assigned:

	this.unit = new CompilationUnitDeclaration(problemReporter, 
compilationResult, 0);

So it feels like some VM issue...
Comment 5 Philipe Mulet CLA 2003-05-23 07:03:21 EDT 
*** Bug 37804 has been marked as a duplicate of this bug. ***
Comment 6 Philipe Mulet CLA 2003-05-27 13:14:15 EDT 
*** Bug 38163 has been marked as a duplicate of this bug. ***
Comment 7 Philipe Mulet CLA 2003-05-27 13:16:00 EDT 
Duplicates look like this is not a VM issue, but rather some concurrency 
problem. Usually next attempt will work. Feels like some intermediate infos 
would be accessed while being populated, and source type converter would get an 
inconsistent set of imports.
Comment 8 Philipe Mulet CLA 2003-06-10 06:38:51 EDT 
*** Bug 38688 has been marked as a duplicate of this bug. ***
Comment 9 Jerome Lanneluc CLA 2003-06-10 07:33:06 EDT 
SourceTypeElementInfo.getImports() was positioning the 'imports' field before 
the computation of the ImportDeclarationElementInfos was finished. As a result, 
another thread asking for imports would get an array with nulls.

Fixed by positioning the 'imports' field when the computation is finished.
Comment 10 Philipe Mulet CLA 2003-06-11 07:14:47 EDT 
Cannot occur in 2.1 maintenance build since bug got introduced in 3.0 branch 
only.
Comment 11 Philipe Mulet CLA 2003-06-24 03:43:53 EDT 
*** Bug 39200 has been marked as a duplicate of this bug. ***
Comment 12 David Audel CLA 2003-07-17 06:16:25 EDT 
Verified.