[jboss-dev] WarAnnotationMetaDataDeployer and AOP failures

Andrew Dinn adinn at redhat.com
Thu Jan 28 10:08:37 EST 2010


[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
-----------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100128/b4222d6d/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: before
Url: http://lists.jboss.org/pipermail/jboss-development/attachments/20100128/b4222d6d/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: after
Url: http://lists.jboss.org/pipermail/jboss-development/attachments/20100128/b4222d6d/attachment-0001.pl 


More information about the jboss-development mailing list