Bug 488004 - AspectJ Internal Error: unable to add stackmap attributes. can't determine implemented interfaces of missing type
Summary: AspectJ Internal Error: unable to add stackmap attributes. can't determine im...
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: 1.8.9   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-18 06:41 EST by Frank Benoit CLA
Modified: 2016-02-19 14:38 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Benoit CLA 2016-02-18 06:41:11 EST
AspectJ Internal Error: unable to add stackmap attributes. can't determine implemented interfaces of missing type config.ItfPipChnlIo$Enmactivationtype
when weaving type prj.lib.TestBench_Lib
when weaving classes 
when weaving 
 [Xlint:cantFindType]
Log4J:FATAL [ModalContext] (Logger.java:133) - java.lang.VerifyError: Expecting a stackmap frame at branch target 93
Exception Details:
  Location:
    prj/lib/TestBench_Lib.dbFct_Connect_DUTs_to_power_supply_aroundBody9$advice(Lprj/lib/TestBench_Lib;Lorg/aspectj/lang/JoinPoint;Lcastle/aspect/LibAspect;Lorg/aspectj/runtime/internal/AroundClosure;Lorg/aspectj/lang/JoinPoint;)V @58: ifeq
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0x0000000: 1904 b902 b701 003a 0519 05c1 02b9 1302
    0x0000010: bb03 bd00 e5b8 02c1 1904 b902 b701 00c0
    0x0000020: 02b9 3a06 1906 b902 c501 003a 0701 3a08
    0x0000030: 1904 b902 c901 00c1 0005 9900 2319 04b9
    0x0000040: 02c9 0100 c000 05b9 02cb 0100 3a08 1908
    0x0000050: 1302 cd03 bd00 e5b8 02d1 a700 3b19 04b9
    0x0000060: 02c9 0100 c102 d399 0023 1904 b902 c901
    0x0000070: 00c0 02d3 b902 d401 003a 0819 0813 02d6
    0x0000080: 03bd 00e5 b802 d1a7 000e 1302 d803 bd00
    0x0000090: e5b8 02dc bf19 04b9 02c9 0100 b602 e0b6
    0x00000a0: 02e3 3a09 1907 b202 e919 04b9 02ed 0100
    0x00000b0: b802 f33a 0a19 0813 02f5 05bd 00e5 5903
    0x00000c0: 1909 5359 0419 0a53 b902 fb03 002d 3a0c
    0x00000d0: 2a2b b803 37a7 000f 3a0b 1908 b903 0401
    0x00000e0: 0019 0bbf 1908 b903 0401 00b1          
  Exception Handler Table:
    bci [205, 216] => handler: 216

The mentioned enum, is in a generated code, compiled with iajc.

in config.jar:
public interface ItfPipChnlIo extends castle.data.RootInterface, Itf_Object {
    public enum Enmactivationtype implements castle.data.IEnum {
        DISABLED("0"),
        ENABLED("1"),
        ;
        private final java.math.BigDecimal value;
        private Enmactivationtype( String value ) {
            this.value = new java.math.BigDecimal(value);
        }
        public java.math.BigDecimal toBigDecimal() {
            return value;
        }
        public int toInt() {
            return value.intValue();
        }
        public double toDouble() {
            return value.doubleValue();
        }
    }
//....
    public void afcBusInjectFault(Enmactivationtype _Fault, Enmbusfaulttype _FaultType);
// ....
}

in base.jar:
public interface IEnum extends ILookup {
    public BigDecimal toBigDecimal();
    public int toInt();
}
public interface ILookup {
    public String name();
    public BigDecimal toBigDecimal();
    public int toInt();
    public double toDouble();
}


The error happens in a place where afcBusInjectFault() is used.
Comment 1 Frank Benoit CLA 2016-02-18 07:07:46 EST
What might be special, in this case is:

there are two interfaces containing a enum with the same name:

interface ItfPipChnlIo {
    enum Enmactivationtype {}
}
interface ItfPip {
    enum Enmactivationtype {}
}

Perhaps this creates the problem?
Comment 2 Andrew Clement CLA 2016-02-18 11:59:31 EST
We use full signatures everywhere so it *shouldnt* be a problem to have two inner enums with the same name. Is there any way you can share the project with me that has the failure? I feel that is the fastest way to resolution. I will try coding up a representative app but I'm not optimistic I can recreate. Possibly related to the $ getting mishandled for the inner type but feels like that would have come up before if it were a problem.
Comment 3 Andrew Clement CLA 2016-02-18 13:39:35 EST
I had a go but I can't trigger the problem. If you can't share a program I'd at least need more info on the kind of pointcut being used and the general flow through the method dbFct_Connect_DUTs_to_power_supply which seems to be the one causing the issue. Stack map frames must be generated at jump destinations in the byte code. So if there are multiple routes through a method, where those routes re-combine is where we would get into trouble like this (where they recombine is where we have to verify every route to that point agrees on the type of the variables and the stack contents). Does the method have lots of branching? Are variables assigned differing flavors of the enum types in those branches?
Comment 4 Frank Benoit CLA 2016-02-19 03:12:28 EST
The aspect looks like this:

public aspect LibAspect {
	
    pointcut libFunc() : 
        ( @annotation(castle.anno.SpecText) || @annotation(castle.anno.ILibExport) )  
        && execution(!static public void *(..) throws !* );

    void around() :libFunc() {
        // ....
    }
}

The method causing the problem:

@SpecText(/*...*/)
public void dbFct_Connect_DUT_to_CASTLE_Private_and_Vehicle_BUS(String DUT)
{
    getPIPChnlIO(DUT).afcBusInjectFault(Enmactivationtype.DISABLED, Enmbusfaulttype.OPENPRIVATEBUS);
    exu.pauseStandard();
    getPIPChnlIO(DUT).afcBusInjectFault(Enmactivationtype.DISABLED, Enmbusfaulttype.OPENVEHICLEBUS);
}
Comment 5 Andrew Clement CLA 2016-02-19 14:38:03 EST
It is perhaps interesting that I think your other bug is related to a missing type problem - since both of these issues would then be related to missing types. Or at least types not being found. AspectJ does not actual type finding itself, instead it relies on the class loaders it is being associated with, using their getResource...() methods to find things. If those methods were misbehaving in some way I could see this happening. For example if the delegation model for class lookup is doing one thing but the delegation model for resource locating is doing something else. (Just thinking out loud here).