Community
Participate
Working Groups
Build Identifier: 20100218-1602 After upgrading to aspectj 1.6.9 I get an error when aspectj try to weave code instrumented by cobertura (it works fine with aspectj 1.6.8). I have created a small Maven project with an aspect in src/main/java and a test class that is weaved. Not that the error occurs only when I use MethodSignature signature = (MethodSignature) jp.getSignature(); in my aspect. Here is an extract of the error: [ERROR] Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:test-compile (aspectj) on project aspectj-it: Compiler errors: abort ABORT -- (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute (length:27)org.aspectj.weaver.BCException: Bad type signature <init> when batch building BuildConfig[null] #Files=2 AopXmls=#0 when batch building BuildConfig[null] #Files=2 AopXmls=#0 malformed org.aspectj.weaver.EffectiveSignature attribute (length:27)org.aspectj.weaver.BCException: Bad type signature <init> when batch building BuildConfig[null] #Files=2 AopXmls=#0 when batch building BuildConfig[null] #Files=2 AopXmls=#0 org.aspectj.weaver.BCException: malformed org.aspectj.weaver.EffectiveSignature attribute (length:27)org.aspectj.weaver.BCException: Bad type signature <init> when batch building BuildConfig[null] #Files=2 AopXmls=#0 when batch building BuildConfig[null] #Files=2 AopXmls=#0 at org.aspectj.weaver.AjAttribute.read(AjAttribute.java:137) at org.aspectj.weaver.bcel.Utility.readAjAttributes(Utility.java:101) at org.aspectj.weaver.bcel.BcelMethod.unpackAjAttributes(BcelMethod.java:184) at org.aspectj.weaver.bcel.BcelMethod.<init>(BcelMethod.java:91) Reproducible: Always Steps to Reproduce: 1.Extract attached test project 2.Run mvn clean cobertura:cobertura
Created attachment 178944 [details] Maven integration test
I hit similar issue on AspjectJ 1.6.12 for my codes =========================================================== ---- Compiler Messages --- info directory classpath entry does not exist: /opt/jdk1.6.0_30/jre/lib/sunrsasign.jar info directory classpath entry does not exist: /opt/jdk1.6.0_30/jre/lib/modules/jdk.boot.jar info zipfile classpath entry does not exist: /opt/jdk1.6.0_30/jre/classes abort ABORT -- (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute (length:27)org.aspectj.weaver.BCException: Bad type signature touch when batch building BuildConfig[null] #Files=5 AopXmls=#0 --------------------------------------------------------------- After I switch to AspectJ 1.7.0.RC1, I don't see this issue but another issue appears: =========================================================== ---- AspectJ Properties --- AspectJ Compiler 1.7.0.RC1 built on Friday May 25, 2012 at 23:23:14 GMT ---- Dump Properties --- Dump file: ajcore.20120615.160521.469.txt Dump reason: java.lang.ClassCastException Dump on exception: true Dump at exit condition: abort ---- Exception Information --- java.lang.ClassCastException: org.aspectj.apache.bcel.classfile.ConstantMethodref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8 at org.aspectj.apache.bcel.classfile.ConstantPool.getConstantUtf8(ConstantPool.java:223) at org.aspectj.weaver.bcel.BcelConstantPoolReader.readUtf8(BcelConstantPoolReader.java:31) at org.aspectj.weaver.VersionedDataInputStream.readUtf8(VersionedDataInputStream.java:61) at org.aspectj.weaver.ResolvedMemberImpl.readResolvedMember(ResolvedMemberImpl.java:500) at org.aspectj.weaver.AjAttribute$EffectiveSignatureAttribute.read(AjAttribute.java:734)
Per the first comment, I downloaded the attached project and ran 'mvn clean compile', it worked OK. It appeared to be using 1.6.9, I tried it with 1.6.8 and same result. The problem with 'Bad type signature' and 'org.aspectj.apache.bcel.classfile.ConstantMethodref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8' both suggest that something has modified the class file and not preserved the constant pool contents/ordering. Some ways of using the Asm bytecode toolkit don't preserve the pool, attempting to optimize it and not recognizing other class file attributes may point into it (not annotations). Wai-Tak, are you using cobertura? Do you know at what point cobertura runs, is it instrumenting source code or bytecode when you run it? Are you loadtime weaving as well or just doing a regular compile? These orderings of operations should be fine: aspectJ compile source > cobertura instruments binaries > code runs ok Java compiles > Cobertura instruments binaries > aspectj binary weave > code runs ok Cobertura instruments sources > AspectJ Compiles > code runs ok Cobertura instruments sources > Java Compiles > AspectJ binary weave > code runs ok This type of ordering won't run, if cobertura affects the contents/ordering of the class constant pool: aspectj compile source > cobertura instruments binaries > second aspectj binary weave (BANG) aspectj compile source > cobertura instruments binaries > loadtime weaving runs (BANG) java compiles > aspectj weave > cobertura instruments binaries > loadtime weave (BANG) It is possible that on a non-clean incremental compile that AspectJ is seeing some files that have been through the cobertura weave step, and is attempting to understand them. With the modified constant pools it cannot understand them and fails. Or if there are multiple compile steps and any one of those steps sees code that originally went through aspectj followed by cobertura - it will fail like this.
unsetting the target field which is currently set for something already released
