Community
Participate
Working Groups
Noticed this when doing a big refactoring, with multiple errors, and changing the name of an overriding method which shadowed a deprecated method in AbstractUiPlugin. Cleaning resolved it. -- Error Log -- Date: Wed May 21 15:53:08 PDT 2008 Message: Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". Severity: Error Plugin ID: org.eclipse.core.resources Stack Trace: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.binarySearch(ReferenceBinding.java:108) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getMethods(ParameterizedTypeBinding.java:565) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1084) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1056) at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2104) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:432) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:387) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:883) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.ForeachStatement.resolve(ForeachStatement.java:518) at org.eclipse.jdt.internal.compiler.ast.Statement.resolveCase(Statement.java:141) at org.eclipse.jdt.internal.compiler.ast.SwitchStatement.resolve(SwitchStatement.java:307) at org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115) at org.eclipse.jdt.internal.compiler.ast.SynchronizedStatement.resolve(SynchronizedStatement.java:196) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:233) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.ForeachStatement.resolve(ForeachStatement.java:518) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:443) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:405) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1095) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:619)
Looks like a dup of bug 170896. We could not get steps to reproduce. Mik, would you be able to extract some steps that could help us to fix this one? Thanks, Olivier
Mik - which build are you running ?
I'm running I20080516-1333. My workspace had way more errors than usual when this happened, and it's unlikely that I will be able to figure out how to get it into that state again. I will report back if I see anything like this again. Sorry that I can't be more helpful, but beyond what I stated in the description I have no idea how to set up a test case or steps for this without understanding the implementation.
This issue likely has to do with a code pass in compiler where the method binding sorting/resolution has not occurred yet... We would need to understand how your workspace is constructed to find out how it could have occurred.
I haven't seen this again (currently on RC3). My workspace has a bunch of Mylyn projects checked out into it, and those are structure identically to how Platform/JDT projects are structured (single source folders, dependencies between plug-ins in the workspace, SDK, and Orbit bundles).
(In reply to comment #5) > I haven't seen this again (currently on RC3). My workspace has a bunch of > Mylyn projects checked out into it, and those are structure identically to how > Platform/JDT projects are structured (single source folders, dependencies > between plug-ins in the workspace, SDK, and Orbit bundles). > I got the same exception today, with the following stack trace (I20080617-2000). It happened when i saved a java file, and a message box explained that a clean up/save action had an error. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.binarySearch(ReferenceBinding.java:108) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getMethods(ParameterizedTypeBinding.java:569) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1084) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1056) at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2111) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:432) at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:187) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.ForStatement.resolve(ForStatement.java:377) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:233) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:100) at org.eclipse.jdt.internal.compiler.ast.ForeachStatement.resolve(ForeachStatement.java:518) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:443) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:405) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1095) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:865) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:518) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:880) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:656) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:540) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:533) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:474) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:129) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:168) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$3.run(SelectionListenerWithASTManager.java:153) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
(In reply to comment #6) I had to say that i switched to a JRockit VM (R27.5.0) today... So Sun VM eats handles, and JRockit produce buggy code, great!
Here's another platform on which this is happening: Ganymede release Version: 3.4.0 Build id: I20080609-1311 Eclipse properties: -vm /usr/java/jrockit-R27.5.0-jdk1.5.0_14/bin/java eclipse.ee.install.verify=false eclipse.home.location=file:/home/rosec/app/eclipse-3.4-RC4/ eclipse.launcher=/home/rosec/app/eclipse-3.4-RC4/eclipse eclipse.p2.data.area=@config.dir/../p2 eclipse.p2.profile=PlatformProfile eclipse.product=org.eclipse.sdk.ide eclipse.startTime=1217945925341 eclipse.vm=/usr/java/jrockit-R27.5.0-jdk1.5.0_14/bin/java eclipse.vmargs=-XX:MaxPermSize=384m -Xmx1024M (Yes, I know that MaxPermSize is not a JRockit option, but it's ignored and I've tried to run on the sun VM and failed recently, so I'm leaving it around)
This may turn out to be a JIT problem with a specific VM or 2. Has anyone seen this problem on a different VM than JRockit VM (R27.5.0) ? Mik - do you remember which VM you were using 3 months ago ?
Sorry for the slow rely. I'm 90% sure that I saw it when using jrockit-26.4 (I've been switching back and forth between that, since it doesn't run out of handles, and the latest Sun VMs including update 10, so there's a chance it was a Sun VM).
To rule out JIT bug, you may want to run with JIT disabled (-Djava.compiler=none)
Closing as JIT issue on JRockit VM If anyone reproduces this on another VM, please reopen & provide as much detail as possible
Verified for 3.5M3
*** Bug 271127 has been marked as a duplicate of this bug. ***
