Community
Participate
Working Groups
The error message appeared when I used a switch (java.lang.String) construct. It went away when I replaced the switch with a series of if (.equals) statements. Don't know if this helps.
some questions: - what is the exact version of plug-in org.eclipse.jdt.core you are using? - can you try using a more recent version? - can you isolate a minimal test case that shows the problem? - please also post the stack trace thanks
These were comments from Erwin, which were made outside bugzilla: (In reply to comment #1) > some questions: > > - what is the exact version of plug-in org.eclipse.jdt.core you are > using? Eclipse Java Development Tools Version: 3.7.2.v20120120-1414-7z8gFcuFMP7BW5XTz0jLTnz0l9B1 Build id: M20120208-0800 > - can you try using a more recent version? I ran the "check for updates" from the help menu and installed all the updates. The problem is still reproducible. I may try Eclipse 4 when I have that up and running. > - can you isolate a minimal test case that shows the problem? I tried narrowing down the class by removing code and/or package dependencies, but then the issue goes away. > - please also post the stack trace Where can I find that ? All that happens is a pop-up window saying Errors occurred during the build. Errors running builder 'Java Builder' on project 'SIRA_PRISE'. info cannot be null There are no log files appearing anywhere.
(In reply to comment #2) > Where can I find that ? All that happens is a pop-up window saying > > Errors occurred during the build. > Errors running builder 'Java Builder' on project 'SIRA_PRISE'. > info cannot be null > > There are no log files appearing anywhere. The logs get stored to a file at the following location: <workspace_location>/.metadata/.log
Created attachment 232492 [details] The .log file containing the stack trace as well as the whole class source
I found this bug, because I get also "info cannot be null" messages in 4.4M3. eclipse.buildId=4.4.0.I20131030-2000 java.version=1.7.0_45 java.vendor=Oracle Corporation BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/claudio/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/claudio/.eclipse_keyring -showlocation Error Sat Nov 02 17:57:38 CET 2013 Error in JDT Core during AST creation java.lang.IllegalArgumentException: info cannot be null at org.eclipse.jdt.internal.compiler.codegen.StackMapFrame.addStackItem(StackMapFrame.java:81) at org.eclipse.jdt.internal.compiler.ClassFile.traverse(ClassFile.java:4561) at org.eclipse.jdt.internal.compiler.ClassFile.generateStackMapTableAttribute(ClassFile.java:3375) at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttribute(ClassFile.java:1190) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:296) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:228) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:562) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:631) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:360) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1206) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:685) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) eclipse.buildId=4.4.0.I20131030-2000 java.version=1.7.0_45 java.vendor=Oracle Corporation BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/claudio/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/claudio/.eclipse_keyring -showlocation Error Sat Nov 02 17:57:38 CET 2013 Problems occurred when invoking code from plug-in: "org.eclipse.jdt.ui". java.lang.IllegalArgumentException: info cannot be null at org.eclipse.jdt.internal.compiler.codegen.StackMapFrame.addStackItem(StackMapFrame.java:81) at org.eclipse.jdt.internal.compiler.ClassFile.traverse(ClassFile.java:4561) at org.eclipse.jdt.internal.compiler.ClassFile.generateStackMapTableAttribute(ClassFile.java:3375) at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttribute(ClassFile.java:1190) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:296) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:228) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:562) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:631) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:360) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1206) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:685) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) I will add my eclipse configuration as attachment.
Created attachment 237149 [details] eclipse configuration
The stacktrace looks similar indeed. Unfortunately it doesn't say much about the situation that triggered the bug. If the bug can be reproduced on your project, could you perhaps extract a small sample project that demonstrates the bug? TIA. Also if Erwin could produce a self contained sample that would greatly help. I tried to use the source from comment 4 but even after creating *many* stub classes for missing dependencies, I could not observe the bug. (I gave up about 40% into the source file - after creating 60+ stub classes).
Sorry, I can't help there as I continued work on that class since the error happened. I tried now to edit and play around in the spot I was working on when the error occurred but cannot reproduce or in any way trigger it.
I've recently encountered this problem in similar circumstances, with the exception that it's not during an incremental build, but it fails when using the Plugin Export Wizard. The log generated within the export directory contains # 07/11/14 15:30:16 GMT # Eclipse Compiler for Java(TM) v20140902-0626, 3.10.0, Copyright IBM Corp 2000, 2013. All rights reserved. ---------- 1. ERROR in C:\temp\testbug\test\src\Test.java (at line 0) ^ Internal compiler error: java.lang.IllegalArgumentException: info cannot be null at org.eclipse.jdt.internal.compiler.codegen.StackMapFrame.addStackItem(StackMapFrame.java:81) (this was from Luna SR1, also failed with Kepler SR2 (v20140317-1741, 3.9.50)) The presence of the following code within the plugin is enough for the plugin export wizard to fail. Eclipse does not have any issues itself with this code. public void testFunction() { int var1 = 0; int var2 = 0; switch ("test") { case "test": var2 = ++var1 % 2; break; } } From testing, a couple changes can be made which make the error go away: 1. move the definition of var1 out of the testFunction 2. split the incrementing of var1 out from the single statement i.e. ++var1; var2 = var1 % 2; Runtime Info: Eclipse Luna SR1 (For RCP and RAP) org.osgi.framework.os.name=Windows7 org.osgi.framework.processor=x86-64 java.version=1.8.0_11 org.eclipse.jdt (3.10.0.v20140925-0400) "Eclipse Java Development Tools" org.eclipse.platform (4.4.0.v20140925-0400) "Eclipse Platform"
Created attachment 248506 [details] Proposed patch The problem was that the code generation was restarted to handle the unused local, but the catch clause of a try statement in the code generation of the switch on strings swallowed the abort method exception. Removing the catch clause fixes it. In fact, I don't think this catch was a good idea at all as it might hide potential bugs in the compiler.
Created attachment 248507 [details] Proposed regression tests Regression tests for the proposed patch. They handle the fact that optimized locals need to be set and they make the problem is reported only once. These are the changes in AbstractMethodDeclaration/Clinit/ConstructorDeclaration. When you reset the code generation, you also need to reset the problem count. Otherwise you can end up reporting all the warnings before the code generation restarts more than once.
(In reply to Olivier Thomann from comment #10) > Created attachment 248506 [details] > Proposed patch > > The problem was that the code generation was restarted to handle the unused > local, but the catch clause of a try statement in the code generation of the > switch on strings swallowed the abort method exception. Removing the catch > clause fixes it. In fact, I don't think this catch was a good idea at all as > it might hide potential bugs in the compiler. Sorry about that. I just looked at this part of the patch and it looks good. I think Jay will take it forward to completion.
(In reply to Olivier Thomann from comment #10) > The problem was that the code generation was restarted to handle the unused > local ... In case the patch doesn't already cover it, while the unused variable may have indicated an issue, the error occurs even when the variable is used.
This program: class X { int foo() { int i=1; boolean b=false; b|=true; int k = 2; --k; k+=3; Integer j = 3; j++; i++; return i++; } } When "Preserver unused local variables" is deselected, fails to produce the "unused local variable" warnings. We have a couple of tests[1] that are looking for these warnings and fail. I suppose the tests shouldn't fail? I will investigate this. [1] ProgrammingProblemsTest.test0046() and test0050().
I would say the tests are bogus. They might be a consequence of not resetting the problem count on restart when we realize that a variable is used. See the changes in AbstractMethodDeclaration/Clinit/ConstructorDeclaration. In your example, all variables are used.
(In reply to Olivier Thomann from comment #15) > I would say the tests are bogus. They might be a consequence of not > resetting the problem count on restart when we realize that a variable is > used. See the changes in > AbstractMethodDeclaration/Clinit/ConstructorDeclaration. > In your example, all variables are used. Hmm.. Looks like I am missing something here. Doesn't that mean we are breaking the fix for bug 185682?
(In reply to Jayaprakash Arthanareeswaran from comment #16) > (In reply to Olivier Thomann from comment #15) > > I would say the tests are bogus. They might be a consequence of not > > resetting the problem count on restart when we realize that a variable is > > used. See the changes in > > AbstractMethodDeclaration/Clinit/ConstructorDeclaration. > > In your example, all variables are used. > > Hmm.. Looks like I am missing something here. Doesn't that mean we are > breaking the fix for bug 185682? Sorry Jay, I was wrong. In your case, the return i++; makes i as being used and restart the code generation. I changed the code to flush problems already reported before the code generation is restarted. In your case, we then lose the warning for b. This is because when the code generation is restarted the local has been marked as used. See line 218 in org.eclipse.jdt.internal.compiler.ast.Reference. The variable is reported as being used and to prevent that from being reported again, it is then marked as used. When the code generation restarts, it does no longer see the variable as being used. I wonder whether this line was added to cover duplicate warnings from being issued because the problem count was not reset on restart. It might be worth to try to comment out this line (218) and line 170 in the same class and restart all the tests. Sorry for missing that change. The catch clause should still be removed, but in the original issue, that fix without the change in AbstractMethodDeclaration/Clinit/ConstructorDeclaration would report the same warning multiple times. Let me know what you think. We can talk about it if needed.
With both lines commented out, all tests in ProgrammingProblemsTest are green.
Created attachment 248642 [details] Better patch
Thank you very much Olivier! Patch looks good to me. I have released in master: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1850eabeac3bdcae6e357d374f46d85ea3488da4
*** Bug 453861 has been marked as a duplicate of this bug. ***
Verified for 4.5 M4 with build I20141209-2000
*** Bug 412777 has been marked as a duplicate of this bug. ***
