Community
Participate
Working Groups
Couldn't reproduce it, but maybe you'll know what the problem is when you have the stack trace : java.lang.NullPointerException at org.eclipse.jdt.internal.core.NameLookup.seekTypesInSourcePackage(NameLookup.java:1079) at org.eclipse.jdt.internal.core.NameLookup.seekTypes(NameLookup.java:989) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:778) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:662) at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1301) at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1317) at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1289)
Can you please specify the version no. of the jdt.core plugin? Thanks!
Sure: org.eclipse.jdt.core_3.8.0.v_C03.jar
Jay, can you please take a look? Thanks!
There appears to be a threading issue in the way how the Java model is used and updated. We sporadically experience the same with different Eclipse versions from 3.7.2 up to 4.4.2 so far. This is with Eclipse 3.7.2: java.lang.NullPointerException at org.eclipse.jdt.internal.core.NameLookup.seekTypesInSourcePackage(NameLookup.java:1086) at org.eclipse.jdt.internal.core.NameLookup.seekTypes(NameLookup.java:989) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:778) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:662) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:621) at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:103) at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:294) at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:136) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getType(PackageBinding.java:127) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.isViewedAsDeprecated(PackageBinding.java:211) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isViewedAsDeprecated(ReferenceBinding.java:1269) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesFor(SourceTypeBinding.java:1413) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.methods(SourceTypeBinding.java:1175) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForFieldsAndMethods(SourceTypeBinding.java:678) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:469) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1184) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:681) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807) And this is with Eclipse 4.4.2: java.lang.NullPointerException at org.eclipse.jdt.internal.core.NameLookup.seekTypesInSourcePackage(NameLookup.java:1119) at org.eclipse.jdt.internal.core.NameLookup.seekTypes(NameLookup.java:1022) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:769) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:663) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:845) at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1277) at org.eclipse.jdt.internal.core.JavaProject.findType(JavaProject.java:1358) at de.gebit.trend.modeller.java.umlmodel.eclipse.EclipseJavaHelper.findType(EclipseJavaHelper.java:1444) at de.gebit.trend.modeller.java.index.source.SourceReferenceVisitor.visit(SourceReferenceVisitor.java:173) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:453) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:212) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) It looks like the array of compilation units returned from IPackageFragment.getChildren() is concurrently modified while being iterated over in NameLookup: IJavaElement[] compilationUnits = pkg.getChildren(); for (int i = 0, length = compilationUnits.length; i < length; i++) { if (requestor.isCanceled()) return; IJavaElement cu = compilationUnits[i]; String cuName = cu.getElementName(); Then suddenly some entry in the array is null, leading to the NPE.
(In reply to Carsten Pfeiffer from comment #4) > There appears to be a threading issue in the way how the Java model is used > and updated. We sporadically experience the same with different Eclipse > versions from 3.7.2 up to 4.4.2 so far. > > It looks like the array of compilation units returned from > IPackageFragment.getChildren() is concurrently modified while being iterated > over in NameLookup: > IJavaElement[] compilationUnits = pkg.getChildren(); > for (int i = 0, length = compilationUnits.length; i < length; i++) { > if (requestor.isCanceled()) > return; > IJavaElement cu = compilationUnits[i]; > String cuName = cu.getElementName(); > > Then suddenly some entry in the array is null, leading to the NPE. That sounds reasonable. But the org.eclipse.jdt.core.IParent.getChildren() should never return in null, at least in the package's case. Do you have a testcase that causes this by any chance?
No, I don't have a testcase, sorry. Looking at OpenableElementInfo.getChildren() I see that the internal array of children is returned. Looking at OpenableElementInfo.addChild(IJavaElement), I see this: System.arraycopy(this.children, 0, this.children = new IJavaElement[length+1], 0, length); this.children[length] = child; Code that calls getChildren() before the last line is executed will get an array where the last element is null. I have no idea whether this is actually the case, but this case can be simply fixed by using a temporary array and assigning it to this.children after the last element has been set (like removeChild() does it).
(In reply to Carsten Pfeiffer from comment #6) > I have no idea whether this is actually the case, but this case can be > simply fixed by using a temporary array and assigning it to this.children > after the last element has been set (like removeChild() does it). Yep, that's something we can do in the absence of reproducible testcase. We can also guard the vulnerable places with a null check.
Hmm, that would be all clients of IParent.getChildren() which would be an awful lot of places to touch. I'd rather check if there are be places where the children array is manipulated and a null element could sneak in.
No progress yet and unlikely to get time during 4.6. Moving out.
Bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
