Bug 135068 - VerifyError with LTW and @AJ style aspects
Summary: VerifyError with LTW and @AJ style aspects
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: 1.5.1   Edit
Hardware: PC Linux
: P2 critical (vote)
Target Milestone: 1.5.2   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-05 12:15 EDT by Igor Fedorenko CLA
Modified: 2006-05-16 09:45 EDT (History)
0 users

See Also:


Attachments
sample project that demonstrates the problem (3.18 KB, application/octet-stream)
2006-04-05 12:23 EDT, Igor Fedorenko CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Fedorenko CLA 2006-04-05 12:15:45 EDT
I get "VerifyError: Incompatible object argument for function call" error when using LTW with @Aspect stype aspects. Interestingly enough, LTW works as expected with equivalent .aj style aspect. Compile time weaving works with both aspect styles. Tested on Linux with AspectJ 1.5.0, 1.5.1 and DEVELOPMENT-20060404163823 and SUN 1.5.0_06 and IBM 1.5.0SR1 JVMs. I will attach example project shortly.
Comment 1 Igor Fedorenko CLA 2006-04-05 12:23:29 EDT
Created attachment 37768 [details]
sample project that demonstrates the problem

Make sure your JAVA_HOME points to Java5 installation and run "ant -f test:ltw" from ajtestjava directory to reproduce the problem.
Comment 2 Wes Isberg CLA 2006-05-10 12:41:44 EDT
Raising priority of verify error, though I haven't validated the test case.
Comment 3 Andrew Clement CLA 2006-05-15 11:47:09 EDT
I've recreated the problem using the supplied testcase.  Currently debugging through it.

On running the class C, which is woven with the around advice, I get:

Exception in thread "main" java.lang.VerifyError: (class: t/C, method: test signature: ()V) Incompatible object argument for function call

LTW isn't required, you can recreate this just compiling source code:

ajc -1.5 -XnoInline -d output t/C.java t/Ajava.java

XnoInline - which causes closure generation, is what leads to the problem.
Comment 4 Andrew Clement CLA 2006-05-16 03:47:58 EDT
the problem here is that the advice in the @AJ case is declared static.  We let that through and then generate code that fails verification at runtime.  If you tried to make code style advice static you would get:

"illegal modifier on advice, only strictfp is allowed"

I've just committed changes to also police this for @AJ aspects - and added a few testcases.

If you make your around advice non-static, everything works fine.
Comment 5 Andrew Clement CLA 2006-05-16 09:45:26 EDT
fix available in latest dev build to police this.