Community
Participate
Working Groups
Found this in .log after upgrading to 3.4.1. The java source have not been touched for a long time, so its valid and have been compiled with older eclipse versions. !SESSION 2008-10-21 15:27:57.010 ----------------------------------------------- eclipse.buildId=M20080911-1700 java.version=1.6.0_07 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=da_DK Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY org.eclipse.core.resources 4 2 2008-10-21 15:36:13.926 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 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:7539) at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttribute(ClassFile.java:1613) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:244) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:179) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:530) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:564) at org.eclipse.jdt.internal.compiler.ast.QualifiedAllocationExpression.generateCode(QualifiedAllocationExpression.java:169) at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.generateCode(ReturnStatement.java:122) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:232) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:179) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:530) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:564) at org.eclipse.jdt.internal.compiler.ast.QualifiedAllocationExpression.generateCode(QualifiedAllocationExpression.java:169) at org.eclipse.jdt.internal.compiler.ast.FieldDeclaration.generateCode(FieldDeclaration.java:104) at org.eclipse.jdt.internal.compiler.ast.Clinit.generateCode(Clinit.java:253) at org.eclipse.jdt.internal.compiler.ast.Clinit.generateCode(Clinit.java:103) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:530) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:581) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:356) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:755) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Unknown Source)
Could you please provide a test case to reproduce ?
That is not as simple as giving a java file, I have tried. It is the same file as reported in https://bugs.eclipse.org/bugs/show_bug.cgi?id=232062 I can comment out everything except one method in the static class in the interface and I will still get the mentioned exception. As soon as the last method is commented out, the exception is gone and I can _not_ get it back by uncommenting (nor by replacing from cvs) The only way to reproduce is by checking out the project again.
I could not reproduce the failure using the test case from bug 232062. If you have a test case that reproduces the pb reliably, it would be good if you could share it even if the test case is pretty big.
I have no small reproducible way of getting this exception. It currently hits me every time the project is rebuild. After rebuild I add a parse error - and eclipse seems to rebuild all and finds the parse error (without throwing the exception). When correcting the parse error everything is ok and only rebuilds the single file.
Would it be possible to get access to this project? I'd like to reproduce it as close as possible from the way you get it to make sure it is fixed once for all. Thanks.
No, but we could do debugging over chat/phone etc.
Is it ok if I send you a patch version so that you can get a dump when the problem occurs ?
Yes.
What is your time zone ?
GMT+2
Patch sent. Please let me know as soon as you can get the dump.
Received and dump sent.
If it is not possible to get access to the source code, is it possible to organize a remote debugging ? I cannot retrieve enough informations through the dumps to reproduce this issue. Would it be possible for you to attach the 3 .class files in question once they compile fine to see the shape of the local variable table? Thanks.
Looking at the 3 .class files, it looks like one of them at least has been produced with the patch. It is missing the StackMap attribute when I would expect it to have some. The only way I see to make progress in this case is to try remote debugging. Would this be possible ?
Peter, Can we try to set up a remote debugging to fix this problem? Thanks.
I am able to reproduce what seems like a similar bug. However like Peter I am not able to extract a simple test case. The good thing though is i can reproduce this bug with latest eclipse 3.5. Need to debug... Where can i find the code for org.eclipse.jdt.internal.compiler.codegen.StackMapFrame (and source) ? lazy me :)
Inside the JDT/Core bundle. If you can provide a test case (even if it is big), I am ready to spend the required time to debug it and understand what is going on. I could also do remote debugging on demand. Let me know what you can provide to fix this issue. I never got an answer from Peter about setting remote debugging with him.
Created attachment 129205 [details] Proposed fix I'll prepare a regression test.
Thanks to Irwin I could get a test case to reproduce the issue. It is related to the way the maxFieldCount is set during the compilation. In this case we had a mismatch between the max field count used in the code stream to find out if a local is definitely assigned and the max field count used in the flow analysis to store the definitely assigned information for locals. So the consequence was that some locals were closed too earlier and therefore the 1.6 stack map frame generation was not capable of retrieving the locals. This caused the IllegalArgumentException. The .class files in 1.5 was also wrong as the local variable range was too short for some locals. I will add a regression test for this one and review the patch with Philippe. Thanks again Irwin for the time we spent over the phone and the time you spent extracting the test case. Peter, once we have a build with the fix in it, would it be possible for you to verify that your test case is also fixed?
Created attachment 129210 [details] Test case Classes do not compile properly.
Philippe, please review the patch.
Created attachment 129213 [details] Proposed fix + regression tests Same patch including regression tests.
Released for 3.5M7. Regression tests added in: org.eclipse.jdt.core.tests.compiler.regression.StackMapAttributeTest#test040 org.eclipse.jdt.core.tests.compiler.regression.StackMapAttributeTest#test041 Review is still required.
Verified for 3.5M7 using build I20090426-2000
I can no longer reproduce the bug with rc3. Nor can I reproduce bug 232062, so it can be closed too. (mentioned in comment #2) Peter
