Summary: | ClassFormatException with tracing aspect | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Dean Wampler <dean> | ||||
Component: | Compiler | Assignee: | Andrew Clement <aclement> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P2 | ||||||
Version: | DEVELOPMENT | ||||||
Target Milestone: | 1.5.0RC1 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Dean Wampler
2005-10-19 14:01:25 EDT
i'll take a look ... Slight correction; the static initializer block should have as its first line: prefixStr = new StringBuffer(1024); It doesn't remove the bug, however. The weaving succeeds for some modules, but not all. Most Junit tests fail to run when invoked ('An internal error occurred during "Launching"'). I simplified the pointcuts: public pointcut exclusions(): within(CallTrace) || within(*Tracer); public pointcut traceIntf(): execution(* com.adteractive..Traced+.*(..)) || execution(com.adteractive..Traced+.new(..)); public pointcut traceAnno(): execution(* @TracedAnno com.adteractive..*.*(..)) || execution(@TracedAnno com.adteractive..*.new(..)); public pointcut trace(): !exclusions() && (traceIntf() || traceAnno()); Object around(): trace() { // same as before } The exception dialog doesn't appear anymore, but I'm still having problems getting some, but not all, junit tests to run. Unfortunately, the "failed to launch" dialog provides no information. The log indicates an array index out of bound exception (value = -1). The only connection to AJ is that this problem didn't occur until I started using the aspect. I restarted eclipse, that wasn't enough. What finally got the tests to work again, with the tracing aspect, was to remove the AJ nature, rebuild, then add the AJ nature back and rebuild. Hmm, looking at this code: org.aspectj.apache.bcel.classfile.ClassFormatException at org.aspectj.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:1293) at org.aspectj.apache.bcel.generic.Type.getTypeInternal(Type.java:166) at org.aspectj.apache.bcel.generic.Type.getTypeInternal(Type.java:174) it seems when the exception is thrown it should include the signature it was having trouble with - I guess that got lost somewhere in the error reporting? In fact, here is the whole of 'typeOfSignature': public static final byte typeOfSignature(String signature) throws ClassFormatException { try { switch(signature.charAt(0)) { case 'B' : return Constants.T_BYTE; case 'C' : return Constants.T_CHAR; case 'D' : return Constants.T_DOUBLE; case 'F' : return Constants.T_FLOAT; case 'I' : return Constants.T_INT; case 'J' : return Constants.T_LONG; case 'L' : return Constants.T_REFERENCE; case '[' : return Constants.T_ARRAY; case 'V' : return Constants.T_VOID; case 'Z' : return Constants.T_BOOLEAN; case 'S' : return Constants.T_SHORT; default: throw new ClassFormatException("Invalid method signature: " + signature); // << this is line 1293 } } catch(StringIndexOutOfBoundsException e) { throw new ClassFormatException("Invalid method signature: " + signature); } } We are probably leaking a 'P' signature out of the compile stage, P being like 'L' but its how we choose to identify parameterized types like Pjava/util/List<Ljava/lang/String;>; Wish I knew what the signature was... Created attachment 28477 [details]
Eclipse log file with stack traces
This is the segment of the eclipse ".log" file that contains the "session" data
where the problem occurred.
Specifically, I think the signature you want is probably ... !STACK 0 org.aspectj.apache.bcel.classfile.ClassFormatException: Invalid method signature: Pcom/adteractive/framework/Filter<TI;TO;>; ... (Near the end of the file.) Filter is an interface. Curiously, it is not advised by the aspect in question. Sorry i've taken so long to get to this Dean :( However, I think I've fixed this. I found a bug in the code that creates generic signatures. There are two ways to grab a signature for a type: getSignature() getSignatureForAttribute() the first may return "PSomeType<LSomeOtherType;>;" whilse the second has to return something in the standard Java form 'LSomeType<LSomeOtherType;>;" - we were incorrectly using the first form when building the signature attribute for a file. Is it easy for you to recreate Dean? So you can try my fix when its available? the latest dev build includes what I think might fix it... I'm closing this as I believe its fixed. Dean, please reopen if you encounter this again. |