Community
Participate
Working Groups
A whole series of Bcweaver tests fail when run on our fast build machine. This seems to be to do with the debug info not being consistently generated. (This is the issue discussed on the 14.08.2003 aj call). The failing tests are: failure testAfterReturning BcweaverModuleTests failure testAfterReturningParam BcweaverModuleTests failure testAfterReturningCheckcastParam BcweaverModuleTests failure testAfterReturningConversionParam BcweaverModuleTests failure testAfterThrowing BcweaverModuleTests failure testAfterThrowingParam BcweaverModuleTests failure testAfter BcweaverModuleTests failure testAfterReturningArgs BcweaverModuleTests failure testFancyAfterReturningArgs BcweaverModuleTests failure testThrowing BcweaverModuleTests failure testLots BcweaverModuleTests failure testWeave BcweaverModuleTests failure testAround BcweaverModuleTests failure testAroundAll BcweaverModuleTests failure testAroundAndOthers BcweaverModuleTests failure testAroundAllAndOthers BcweaverModuleTests failure testBefore BcweaverModuleTests failure testStaticTjp BcweaverModuleTests failure testBefore BcweaverModuleTests failure testFancyId BcweaverModuleTests failure testId BcweaverModuleTests failure testHello BcweaverModuleTests failure testFancyHello BcweaverModuleTests failure testBefore BcweaverModuleTests failure testBeforeCflow BcweaverModuleTests failure testBeforePerThis BcweaverModuleTests failure testPublic BcweaverModuleTests failure testPrintln BcweaverModuleTests failure testMumble BcweaverModuleTests failure testFooBar BcweaverModuleTests failure testGetOut BcweaverModuleTests failure testAdd BcweaverModuleTests failure testNot BcweaverModuleTests failure testState BcweaverModuleTests failure testNoResidueArgs BcweaverModuleTests failure testCflowState BcweaverModuleTests failure testTraceJar BcweaverModuleTests failure testStaticTjp BcweaverModuleTests failure testEnclosingStaticTjp BcweaverModuleTests failure testTjp BcweaverModuleTests failure testAroundTjp BcweaverModuleTests failure testAround2Tjp BcweaverModuleTests see any of the build reports for details of the failures.
*** Bug 41596 has been marked as a duplicate of this bug. ***
Now I've taken delivery of my new fast laptop, I can recreate this bug locally :) I've done some investigating and found out that the reason there are differences being detected between the actual and expected output is because the label generation code is producing 'more' labels in the failing case, the particular labels are for 'finally instructions'. if I run the 'beforeWeaveTestCase' standalone, and dump out the contents of the 'main' method for the FancyHelloWorld class *before any munging* it says: In the failing case: public static void main(String[]): GETSTATIC java.lang.System.out Ljava/io/PrintStream; (line 9) ASTORE_1 finally -> E2 | catch java.lang.Exception -> E1 | | ALOAD_1 // java.io.PrintStream out (line 11) | | LDC "bye" | | INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/String;)V | | GOTO L1 | catch java.lang.Exception -> E1 | E1: ASTORE_2 (line 12) | ALOAD_1 // java.io.PrintStream out (line 13) | ALOAD_2 // java.lang.Exception e | INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/Object;)V finally -> E2 GOTO L1 E2: ASTORE 4 (line 14) JSR L0 ALOAD 4 ATHROW L0: ASTORE_3 ALOAD_1 // java.io.PrintStream out (line 15) LDC "finally" INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/String;)V RET 3 (line 16) finally -> E2 | L1: JSR L0 (line 14) finally -> E2 RETURN (line 17) end public static void main(String[]) And in the working case (the difference appears to be the finally stuff at the end of the above version isnt in this version): public static void main(String[]): GETSTATIC java.lang.System.out Ljava/io/PrintStream; (line 9) ASTORE_1 finally -> E1 | catch java.lang.Exception -> E0 | | ALOAD_1 // java.io.PrintStream out (line 11) | | LDC "bye" | | INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/String;)V | | GOTO L0 | catch java.lang.Exception -> E0 | E0: ASTORE_2 (line 12) | ALOAD_1 // java.io.PrintStream out (line 13) | ALOAD_2 // java.lang.Exception e | INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/Object;)V finally -> E1 GOTO L0 E1: ASTORE 4 (line 14) JSR L1 ALOAD 4 ATHROW L0: JSR L1 GOTO L2 L1: ASTORE_3 ALOAD_1 // java.io.PrintStream out (line 15) LDC "finally" INVOKEVIRTUAL java.io.PrintStream.println (Ljava/lang/String;)V RET 3 (line 10) L2: RETURN (line 17) end public static void main(String[]) You can see the extra labels in the failing case. Further exploring it I added some printlns to the org.apache.bcel.generic.MethodGen class, in the ctor. Just after the code that retrieves the exception table CodeException[] ces = c.getExceptionTable(); I asked it to display the exception tables for the FancyHelloWorld.main method: In the failing case there are 3: CodeException(start_pc=4,end_pc=13,handler_pc=13,catch_type=36) CodeException(start_pc=4,end_pc=19,handler_pc=22,catch_type=0) CodeException(start_pc=39,end_pc=42,handler_pc=22,catch_type=0) And in the working case there are just 2: CodeException(start_pc=4,end_pc=13,handler_pc=13,catch_type=36) CodeException(start_pc=4,end_pc=19,handler_pc=22,catch_type=0) So: Why is the 3rd one created in the first case? Given that no munging has taken place, I can't even blame that code. Why does it only happen on fast machines? (I think its the machine and not a subtlely different fix level of the JVM I've got installed)
In the UnwovenClassFile ctor, I displayed the size of the byte array being used to construct the instance. In the failure case: FancyHelloWorld:1045bytes In the working case: FancyHelloWorld:1037bytes
Ok - I didnt realise that for FancyHelloWorld we just use the .class files as built by eclipse. So the problem appears to be some JDT compiler configuration. Having just tested compilation of FancyHelloWorld with a few different JVMs, I get the following sizes for .class files: IBM141 1102bytes SUN142 1113bytes SUN131 1086bytes IBM131 1078bytes So, my assumption now is that it fails on the LAKEBA build machine because it doesn't compile FancyHelloWorld with the JDT compiler...
Aha.. I took the JDT compiler from my working system (jdtcore.jar). I called the compiler from the command line whilst in the weaver/testsrc directory: java org.eclipse.jdt.internal.compiler.batch.main -d ..\bin\. -g *HelloWorld.java Then ALL the bcweaver tests worked.
So, the problem is that the class files generated from HelloWorld etc. are really inputs to the tests, and not outputs. I compiled them using ajc (an Eclipse 2.1.1 based compiler), and put the resulting .class files in testdata/bin. Then I changed the testcase to pick the class files up from that location, rather than from weaver/bin. Everything passes. Result is that when we rev the Eclipse jdt.core inside aspectj again we may need to update the class files in testdata/bin too. I've left a readme in the directory to that effect. Looking forward to clean build reports at long last :)
updating target flag to indicate inclusion in 1.2 release.
