Community
Participate
Working Groups
What steps will reproduce the problem? 1. 2. 3. -- Error Details -- Date: Thu Mar 18 19:45:16 CDT 2010 Message: Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". Severity: Error Product: Eclipse SDK 3.6.0.v201003062000 (org.eclipse.sdk.ide) Plugin: org.eclipse.core.resources Session Data: eclipse.buildId=N20100306-2000 java.version=1.6.0_17 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/chrisaniszczyk/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86 -keyring /Users/chrisaniszczyk/.eclipse_keyring -showlocation Exception Stack Trace: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.missingTypeInMethod(ProblemReporter.java:5113) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:448) at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:221) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:263) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:451) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:212) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:410) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1147) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1226) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1046) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1235) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:531) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:759) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:637)
Chris, would you have steps to reproduce? We had that problem in the past, but we were never capable of reproducing it.
This would occur when we tagged a method binding with the missing tag bits and we cannot find a missing type binding in it. If you could reproduce, please send me your workspace. This would fix a problem reported in the past that we could never reproduce.
This looks like a duplicate of bug 269208. It would be nice if we could get a reproducable case for it, so that we finally fix it once for all.
I might have found what path is causing this problem. Are you calling generic methods using type arguments in your code ? If yes, this might be the cause of the problem when missing types are located inside the type arguments.
I'm simply getting this on a save in my workspace occasionally.
Do you have some classpath issues that could lead to getting missing type bindings ?
Do you have anything in the .log file ?
If you get it frequently enough, would you mind trying a patched version of JDT/Core ?
*** Bug 309396 has been marked as a duplicate of this bug. ***
Olivier, I'm all for trying a patch.
Antoine, If you are getting the NPE very often, I'll send you a patched version of JDT/Core tomorrow.
Created attachment 165033 [details] .log file Olivier, here is my .log file. I can not reproduce the bug anymore, I got rid of it by adding a few more package imports and going on with the resolution of the dependencies of the project. Nevertheless, there are quite a few exceptions in there that could be of interest for you.
I released a debug trace that will show the method binding in the console in case this happens again. This might help us to reproduce this issue and get it fixed.
I20100414-1200 Just happend to me with a fresh egit workspace. A clean and fullbuild fixed it. Will try to attach the whole workspace if that helps. Stacktrace is: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.missingTypeInMethod(ProblemReporter.java:5150) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:448) at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:221) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:263) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:451) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:212) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:410) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1147) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1235) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:531) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:759) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:619)
Created attachment 165843 [details] full egit workspace Attached is the whole workspace where this happend.
(In reply to comment #14) > I20100414-1200 > Just happend to me with a fresh egit workspace. A clean and fullbuild fixed it. How did you build it initially?
Checked out the JGit and Egit bundles (http://wiki.eclipse.org/EGit/Contributor_Guide#Obtaining_Sources), so far so good (some compile errors left due to missing deps). Then I checked out the dependencies from Orbit with the psf (http://wiki.eclipse.org/EGit/Contributor_Guide#Libraries_from_Orbit) and as far as I remember, it crashed after checking out the deps and recompiling the workspace.
(In reply to comment #17) > Checked out the JGit and Egit bundles > (http://wiki.eclipse.org/EGit/Contributor_Guide#Obtaining_Sources), so far so > good (some compile errors left due to missing deps). Then I checked out the > dependencies from Orbit with the psf > (http://wiki.eclipse.org/EGit/Contributor_Guide#Libraries_from_Orbit) and as > far as I remember, it crashed after checking out the deps and recompiling the > workspace. Did you use sources from master or 0.7 ? I tried to reproduce, but for now unsuccessfully.
(In reply to comment #15) > Created an attachment (id=165843) [details] > full egit workspace > Attached is the whole workspace where this happend. I could not directly use this workspace. I cannot open it properly without tons of errors. When I tried to rebuild it from scratch, the problem doesn't happen. I don't have a Mac though.
I used the sources from master. And what I'm a little confused about: it happend once and after a clean build, it didn't happen anymore. Maybe is only occurs without all projects (eg. compiler jumps in while checking out the dependencies but not everything is there yet). Is there anything I could do when it happens again to provide more informations? And btw: the workspace was build on linux, Chris has a Mac as platform.
(In reply to comment #20) > I used the sources from master. And what I'm a little confused about: it > happend once and after a clean build, it didn't happen anymore. Maybe is only > occurs without all projects (eg. compiler jumps in while checking out the > dependencies but not everything is there yet). Is there anything I could do > when it happens again to provide more informations? In latest builds, I adding a debug statement, so the .log file should contain the toString() of the corresponding method binding. Hopefully this will help to narrow this issue down. We could never get it more than once which makes it really difficult to fix.
Created attachment 169560 [details] test project with 2 classes Here is a test project that reproduces this NPE very easily. The debug trace displays: Writing new class file JoinImpl.class ... Could not find missing types in public Set#RAW getJoins(). It's hard to narrow the test case down much further than this since if you open the FromImpl class you get a continuous stream of NPEs in the error log. The example is non-compiling, I don't hit the NPE when properly compiling this code in it's original project (it's from the EclipseLink project, part of Eclipse RT) I am on Windows with a 1.6 JRE.
OK, thanks Karen. I am getting it easily now. Investigating to see if this is still fixable for 3.6. We might have to wait for 3.6.1.
Created attachment 169857 [details] Proposed fix + regression test
Created attachment 170031 [details] Proposed fix + regression test This new patch will definitely remove the NPE. I keep a log entry when the collected missing types are still null.
Srikanth, please review.
Released for 3.7M1. Waiting for code review to release in 3.6.1.
(In reply to comment #27) > Released for 3.7M1. > Waiting for code review to release in 3.6.1. Sorry for the delay, patch looks good. The methods org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.ParameterizedGenericMethodBinding(MethodBinding, RawTypeBinding, LookupEnvironment) org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.ParameterizedGenericMethodBinding(MethodBinding, TypeBinding[], LookupEnvironment) org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding.instantiateGetClass(TypeBinding, MethodBinding, Scope) continue to copy over the tagbits from the original methods without clearing the missing types bit -- Is this intentional ?
(In reply to comment #28) > (In reply to comment #27)org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.ParameterizedGenericMethodBinding(MethodBinding, > RawTypeBinding, LookupEnvironment) org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.ParameterizedGenericMethodBinding(MethodBinding, > TypeBinding[], LookupEnvironment) org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding.instantiateGetClass(TypeBinding, > MethodBinding, Scope) > continue to copy over the tagbits from the original methods without > clearing the missing types bit -- Is this intentional ? I would say yes, since we are not clearing any part of the method binding. The problem was coming from the raw instantiation that was clearing part of the binding without also clearing the corresponding bits. I'll release the patch shortly.
Released for 3.6 maintenance.
Verified for 3.7M1 using build I20100802-1800.
Keeping the RESOLVED STATUS as this needs to be verified for 3.6.1
Verified for 3.6.1 RC2 using Build id: M20100825-0800
*** Bug 321277 has been marked as a duplicate of this bug. ***
