Bug 290087 - VerifyError : Declare parents does not properly rewrite super constructor call, since 1.6.4 present in 1.6.5
Summary: VerifyError : Declare parents does not properly rewrite super constructor cal...
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Linux
: P2 major (vote)
Target Milestone: 1.6.6   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-22 00:04 EDT by Simone Gianni CLA
Modified: 2009-09-22 16:33 EDT (History)
1 user (show)

See Also:


Attachments
Two projects that combined together as explained cause the error (6.19 KB, application/octet-stream)
2009-09-22 00:06 EDT, Simone Gianni CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simone Gianni CLA 2009-09-22 00:04:42 EDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2009010218 Gentoo Firefox/3.0.5
Build Identifier: 20090619-0625 AspectJ 1.6.5

I have the following set of classes :

public class Bean {}
public class GenericParent<T> {
  public GenericParent(Class<? extend T> clazz) {}
}
public class BeanChild extends GenericParent<Bean> {
  public BeanChild(Class<? extends Bean> c) {
    super(c);
  }
}

I have them in a jar, which is added to the inpath of another project. In this second project I have the following classes :

public interface Interface {}
public class InterfaceParent<T extends Interface> extends GenericParent<T> {
  public InterfaceParent(Class<? extends T> c) {
    super(c);
  }
}

And then an aspect that instruments Bean and BeanChild like this :
public aspect BeanHasInterface {
  declare parents : Bean implements Interface;
  declare parents : BeanChild extends InterfaceParent<Bean>;
}

I obtain a VerifyError on BeanChild, caused by the fact that even if it now extends InterfaceParent, it still calls GenericParent.<init> in its constructor.


Reproducible: Always

Steps to Reproduce:
1. Unzip the two atteched projects
2. If you want to, build the first one (TestDifferentParent) and then export it to its jar, otherwise the jar is already there.
3. Build the second one, having the jar from the first one on the inpath.
4. javap -verbose oaj.test.BeanChild to see the error inside the constructor



This works perfectly in 1.6.3.

I noticed this error in 1.6.4, but it was unclear what was going on and then it disappeared changing the code. I'm now facing it again in 1.6.5 .

It happens on both load time weaving and compile time weaving.

It DOES NOT happen if all classes are in a single project, so it seems like it's somewhat related to processing bytecode. 

I'm reporting it as major cause of the VerifyError.
Comment 1 Simone Gianni CLA 2009-09-22 00:06:28 EDT
Created attachment 147756 [details]
Two projects that combined together as explained cause the error
Comment 2 Simone Gianni CLA 2009-09-22 00:08:38 EDT
My current output from javap is :

Compiled from "BeanChild.java"
public class oaj.test.BeanChild extends oaj.test.InterfaceParent
  SourceFile: "BeanChild.java"
  org.aspectj.weaver.WeaverVersion: length = 0xC
[......]
{
public oaj.test.BeanChild(java.lang.Class);
  Signature: length = 0x2
   00 08
  org.aspectj.weaver.MethodDeclarationLineNumber: length = 0x8
   00 00 00 05 00 00 00 51
  Code:
   Stack=2, Locals=2, Args_size=2
   0:   aload_0
   1:   aload_1
   2:   invokespecial   #11; //Method oaj/test/GenericParent."<init>":(Ljava/lang/Class;)V
   5:   return
  LocalVariableTable:
   Start  Length  Slot  Name   Signature
   0      6      0    this       Loaj/test/BeanChild;
   0      6      1    c       Ljava/lang/Class;

  LineNumberTable:
   line 6: 0
   line 7: 5
}                            

As you can see, oaj.test.BeanChild extends oaj.test.InterfaceParent but at opcode 2 it invokes GenericParent.<init> instead of InterfaceParent.<init>
Comment 3 Andrew Clement CLA 2009-09-22 12:44:11 EDT
interesting.  I did make changes in the super rewrite code in that timeframe, I guess we had no testcases for this kind of scenario so my change addressed the problem i was facing but broke this case.
Comment 4 Andrew Clement CLA 2009-09-22 16:33:02 EDT
fix committed.  The rewriter for supers did not go from the parameterized type
to the generic type so failed to recognize there was a super to rewrite.  Now
it dereferences to the generic type and successfully manages a rewrite.