[resent form the correct account this time]

On 01/27/2010 08:56 PM, Kabir Khan wrote:

Flavia and I have upgraded AOP in AS to 2.1.8.GA which gets rid of all the AOP errors
https://jira.jboss.org/jira/browse/JBAS-7618

Hmm, interesting, I upgraded my AS and now get an error out of aopc. Or rather I get a verify error from the code it generates:

13:04:25,428 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.jbossts.baframework.demo.service.HotelImpl: java.lang.ClassFormatError: Invalid length 170 in LocalVariableTable in class file org/jboss/jbossts/baframework/demo/service/HotelImpl
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    . . .

The offending routine is HotelImpl.getHotelData()

Here's the relevant before bytecode (I'll spare you all the details but the two versions are attached:

public java.lang.String getHotelData();
  Code:
   Stack=2, Locals=6, Args_size=1
   0:    getstatic    #9; //Field log:Lorg/apache/log4j/Logger;
   3:    ldc    #60; //String getHotelData()
   . . .
   153:    aload_1
   154:    invokevirtual    #66; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;
   157:    areturn

   . . .
  LocalVariableTable:
   Start  Length  Slot  Name   Signature
   57      24      4    customer       Lorg/jboss/jbossts/baframework/demo/service/CustomerEntityImpl;
   37      47      3    i$       Ljava/util/Iterator;
   119      24      5    room       Lorg/jboss/jbossts/baframework/demo/service/RoomEntityImpl;
   97      49      4    i$       Ljava/util/Iterator;
   0      158      0    this       Lorg/jboss/jbossts/baframework/demo/service/HotelImpl;
   25      133      1    sb       Ljava/lang/StringBuffer;
   30      128      2    customers       Ljava/util/List;
   89      69      3    roomEntities       Ljava/util/List;


and here is the after version:

public java.lang.String getHotelData();
  Code:
   Stack=2, Locals=6, Args_size=1
   0:    getstatic    #341; //Field org/jboss/jbossts/baframework/demo/service/HotelImpl.log:Lorg/apache/log4j/Logger;
   3:    ldc_w    #343; //String getHotelData()
   6:    invokevirtual    #345; //Method org/apache/log4j/Logger.info:(Ljava/lang/Object;)V
   . . .
   159:    aload_1
   160:    invokevirtual    #397; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;
   163:    areturn

    . . .
  LocalVariableTable:
   Start  Length  Slot  Name   Signature
   63      26      4    customer       Lorg/jboss/jbossts/baframework/demo/service/CustomerEntityImpl;
   41      51      3    i$       Ljava/util/Iterator;
   129      26      5    room       Lorg/jboss/jbossts/baframework/demo/service/RoomEntityImpl;
   105      53      4    i$       Ljava/util/Iterator;
   0      170      0    this       Lorg/jboss/jbossts/baframework/demo/service/HotelImpl;
   29      141      1    sb       Ljava/lang/StringBuffer;
   34      136      2    customers       Ljava/util/List;
   97      73      3    roomEntities       Ljava/util/List;

So, the offending entry is the one for 'this' which has been pushed off the end of the bytecode.

Since this AS includes javassist 3.11.0 this may relate to introduction of my patch to 3.10 correcting a previous error in updating local variable tables. In particular I am suspicious about all the ldc_w instructions which replace ldc. The 170 offset for 'this' is 6 greater than it should be and there are 6 ldc_w instructions in the method. I notice also that the start and end positions for e.g i$ and sb which both follow two ldc instructions are out by 2 in the new version. Similarly, roomEmtities is 4 beyond where it should be and follows 4 ldc instructions My fix might possibly have performed a counting error in places where javassist is replacing ldc with ldc_w but I didn't directly modify any of the code which counted changes in length. I think more likely I have unmasked an existing error in counting length changes which did not previously trip the verifier but has done so now because my update is inserting new extents and they now go off the end of the bytecode. I will investigate further.

regards,


Andrew Dinn
-----------