Bugzilla – Full Text Bug Listing
| Summary: | NPE in FieldReference.optimizedBooleanConstant | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Sergey Prigogin <eclipse.sprigogin> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr, eclipse.sprigogin, jarthana, manoj.palat, stephan.herrmann, sxenos, tparker |
| Version: | 3.7 | ||
| Target Milestone: | 4.6 M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://git.eclipse.org/r/46957 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=48ceb5ac4a314c1ce7f6900fe3c64b02824b66f2 |
||
| Whiteboard: | |||
It seems I can reconstruct just from the stack trace: public class Bug361039 { public Bug361039(boolean b) { } private Object foo() { return new Bug361039(!((Boolean)this.f)); } } Here the issue is caused by an unresolved field f. Can you confirm that you had a compiler error like: "f cannot be resolved or is not a field"? (In reply to comment #1) > Here the issue is caused by an unresolved field f. > Can you confirm that you had a compiler error like: > "f cannot be resolved or is not a field"? The code compiles fine with javac. Eclipse compiler doesn't produce any errors either, but I don't know if it's because of the NPE or not. Thanks for the test Stephan! Seems like a long standing issue. Looks like optimizedBooleanConstant() needs a null check. (Assigning to myself for now, let me know if you have a patch and want to release it). (In reply to comment #3) > ... (Assigning to myself for now, let me know if you have a patch and > want to release it). Go ahead, I don't have a patch. (In reply to comment #2) > The code compiles fine with javac. Eclipse compiler doesn't produce any errors > either, but I don't know if it's because of the NPE or not. This actually worries me a bit: from the stacktrace we have pretty strong indication that a field reference was unresolvable or had some other problem. The example in comment 1 shows the same characteristics as your stacktrace. If indeed javac compiles the original code and if the compiled code runs fine, I'd very much appreciate a small example program that exhibits this issue. Would it be possible to isolate the problem into s.t. you can share? (In reply to comment #4) > Would it be possible to isolate the problem into s.t. you can share? Is there a tracing option that can be used to narrow it down to a particular file? Right now the only thing we know that it happens on a large body of code that compiles fine with javac. (In reply to comment #5) > (In reply to comment #4) > > Would it be possible to isolate the problem into s.t. you can share? > > Is there a tracing option that can be used to narrow it down to a particular > file? Right now the only thing we know that it happens on a large body of code > that compiles fine with javac. Mh, doesn't the exception also show up as an error in the Problems view? That should take you to the offending class, no? Inside that class you might want to search using the following regex [1]: return new .*\(.*!.*\(.oolean\) If you don't know the class searching all files in the project might still help, since the thing we are looking for is pretty specific already. [1] Please use a File Search and tick [x] Regular expression New Gerrit change created: https://git.eclipse.org/r/46957 (In reply to Eclipse Genie from comment #7) > New Gerrit change created: https://git.eclipse.org/r/46957 Thanks! Would you also have a JUnit for this? I'd suggest to put it in /org.eclipse.jdt.core.tests.compiler/src/org/eclipse/jdt/core/tests/compiler/regression/FieldAccessTest.java I'm still puzzled by the difference that my repro in comment 1 requires a compile error to trigger the bug whereas Sergey is seeing the exception with no compile error around ... The reason for being pedantic: if the situation indeed arises without a compile error, then the provided patch might actually be wrong. (In reply to Stephan Herrmann from comment #8) > The reason for being pedantic: if the situation indeed arises without a > compile error, then the provided patch might actually be wrong. The NPE happens with a code that compiles with javac without errors, but the patch may still be beneficial because it would allow Eclipse compiler to proceed and to report an error if it thinks that the code is invalid. If the NPE happens without an error, the patch seems harmless. (In reply to Sergey Prigogin from comment #9) > If the NPE happens without an error, the patch seems harmless. Why do you think so? If the bug is still reproducible on your side we should really identify the source location. If the search mentioned in comment 6 yields no hit, then we clearly haven't understood the bug. In this case I suggest to remote-debug Eclipse: + launch main Eclipse with -Xdebug and friends into your main workspace + launch second Eclipse with just JDT/Core in the workspace and a breakpoint on NPE, connect to the main Eclipse, wait for breakpoint hit and inspect the AST elements available from stack frames near the top. (In reply to Stephan Herrmann from comment #10) > (In reply to Sergey Prigogin from comment #9) > > If the NPE happens without an error, the patch seems harmless. > > Why do you think so? The null check is still needed in the scenario explained in comment #1. There is likely another problem behind this bug that still has to be investigated, but the the investigation can be done with or without the null check. > If the bug is still reproducible on your side we should really identify the > source location. If the search mentioned in comment 6 yields no hit, then we > clearly haven't understood the bug. In this case I suggest to remote-debug > Eclipse: > + launch main Eclipse with -Xdebug and friends into your main workspace > + launch second Eclipse with just JDT/Core in the workspace and a breakpoint > on NPE, connect to the main Eclipse, wait for breakpoint hit and inspect the > AST elements available from stack frames near the top. Good point. We'll try to do something. I've asked the original reporter of the bug for more information about his workspace and project. Does the gerrit patch address the issue described in comment 1? Tentatively targeting 4.6. Stephan, hope you are okay with being the QA contact for this one. Since we don't have information about the source code that originally triggered the exception all we have is a stacktrace. I created a JUnit from my reverse-engineered example in comment 1. Final Hudson tests are running (patch set 6). I should add that once we release this fix we'll probably never learn what caused the NPE on code without compile errors (if that was the case) - that bug will just go into hiding. Gerrit change https://git.eclipse.org/r/46957 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=48ceb5ac4a314c1ce7f6900fe3c64b02824b66f2 (In reply to Eclipse Genie from comment #16) > Gerrit change https://git.eclipse.org/r/46957 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=48ceb5ac4a314c1ce7f6900fe3c64b02824b66f2 > Released the fix for the problem witnessed by comment 1 for 4.6 M3 (In reply to Stephan Herrmann from comment #17) > Released the fix for the problem witnessed by comment 1 for 4.6 M3 Is there more to the fix? Should this be moved out to M4? (In reply to Jay Arthanareeswaran from comment #18) > (In reply to Stephan Herrmann from comment #17) > > Released the fix for the problem witnessed by comment 1 for 4.6 M3 > > Is there more to the fix? Should this be moved out to M4? No, let's just close it at this. I just wanted to give Sergey a chance to follow-up on his claim that the bug can be triggered without a compile error :) (In reply to Stephan Herrmann from comment #19) Unfortunately the problem is not easily reproducible so I wasn't able to get additional information. There is a possibility that a bug in the code was introduced by an annotation processor that produced bad code under ecj but not under javac. (In reply to Sergey Prigogin from comment #20) > (In reply to Stephan Herrmann from comment #19) > Unfortunately the problem is not easily reproducible so I wasn't able to get > additional information. There is a possibility that a bug in the code was > introduced by an annotation processor that produced bad code under ecj but > not under javac. Perhaps our fix swept that annotation processor bug under the rug. So may the rug contain it :) Verified for Eclipse Neon (4.6) Build id: I20151028-2000 |
java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.ast.FieldReference.optimizedBooleanConstant(FieldReference.java:488) at org.eclipse.jdt.internal.compiler.ast.CastExpression.optimizedBooleanConstant(CastExpression.java:458) at org.eclipse.jdt.internal.compiler.ast.UnaryExpression.resolveType(UnaryExpression.java:287) at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolveType(AllocationExpression.java:317) at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:225) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:260) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:260) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:260) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:463) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:252) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:422) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1148) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1258) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:538) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:763) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:679) The problem is 100% reproducible but, unfortunately, only on proprietary code.