Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ajdt-dev] AspectJ 1.6.4 bug on getParameterNames 
Hi devs,
the short version first :
- Recompiling with 1.6.4 no problem, the problem happens with compiled 1.6.3 then running with 1.6.4 rt LTW. - Tracing it down seems like BCEL is giving wrong data (LazyClassGen.initializeTjp receives from BCEL 1 parameter name and no parameter types) - BUT the javap of the same ITD aspect compiled with 1.6.4 (working) and 1.6.3 (not working) are identical.
I'm a bit lost. I'll have continuum recompile and redeploy everything with 1.6.4 and the bug will go away, but IMHO it's worth investigating cause could happen again with next versions. 

Now the long version ...

I was lucky enough to find the bug in the first 20 calls to factory.

When Factory.makeMethodSig is called, these are parameters :
modifiers "1" (id=42) methodName "handle_default" (id=3108) declaringType "org.apache.magma.website.RootWebHandler" (id=3093) paramTypes "" (id=49) paramNames "arg0:" (id=3110) exceptionTypes "" (id=49) returnType "org.apache.magma.website.WebHandler" (id=48) As you can see, there is a misterious "arg0" parameter, but no parameter type. The factory method is called by the <cinit> of the following, very simple, aspect : 

public aspect InstallWelcome {

   public WebHandler RootWebHandler.handle_default() {
       return new WelcomeWebHandler();
   }
}
The call is generated by 1.6.4 (cause LTW is running with 1.6.4), but the original aspect is compiled with 1.6.3 and with -XterminateAfterCompilation. 

(mostly useless) stack trace follows :
Factory.makeMethodSig(String, String, String, String, String, String, String) line: 160 InstallWelcome.<clinit>() line: 22 RootWebHandler.handle_default() line: 1 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 RootWebHandler(WebHandler).find(String[]) line: 132 RootWebHandler(WebHandler).find(String) line: 112 Dispatch.findProducer(String) line: 269 Dispatch.handle(HttpServletRequest, HttpServletResponse) line: 99 Dispatch.doGet(HttpServletRequest, HttpServletResponse) line: 63 Dispatch(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 707 Dispatch(HttpServlet).service(ServletRequest, ServletResponse) line: 820 ServletHolder.handle(ServletRequest, ServletResponse) line: 502 Now I'll try to dig a little inside the class generating these calls, which is LazyClassGen.initializeTjp .
It turns out BCEL is giving false informations, since when we arrive to the method, the signature say :
name "handle_default" (id=874) parameterAnnotationTypes null parameterNames String[1] (id=875) parameterTypes UnresolvedType[0] (id=876) paramSignature null reportedCantFindDeclaringType false As you can see, there is a spurious parameter name (for the curious : "arg0" :D ), but no parameterTypes, and strangely enough no paramSignature (usually it is "()" for all other methods I've seen).
Since BCEL is obtaining this data parsing the aspect .class file, next step is a javap of the aspect ... 1.6.4 and 1.6.3 produced bytecode are identical. Since it is not weaved, there is no call to makeMethodSig to see what parameter are passed. 

So, I'm lost :D
I don't know which modifications in BCEL can cause that behaviour, there has not been such a problem from AspectJ 1.6.2 to 1.6.3. 

Simone





Simone Gianni wrote:

Hi Andy,
I tried to reproduce it in a simple test case but yet no success.

Just to give a bit more pointers :
- We're running in LTW, not tested if it happens in build time weaving
- Everything is compiled with 1.6.3, we were just running it with 1.6.4 LTW - Classes and aspects are compiled using -XterminateAfterCompilation to avoid LTW reweaving errors after other bytecode manipulators (like JPA or Cobertura ones) - The method on which the wrong parameter names are reported is called using reflection (but the pointcut is execution(), so should not give problems) - The method on which the wrong parameter names are reported is an ITD method - It happens always, also on different machines, with 1.6.4, while with 1.6.3 everything works always smoothly
I tried to reproduce all this in a simple test program, with a method having an argument calling (using reflection) a no-arg method and a ITD no-arg method, compiling with 1.6.3 -XterminateAfterCompilation and running it using the agent and the "aj" command, but still cannot reproduce the problem.
Tomorrow I'll try debugging Factory.makeMethodSig to see when it is called with param names but no param types, unfortunately debugging in such a large system will take up a lot of time, a small test case would have been m,uch much better :( 

Simone

Andy Clement wrote:

No idea, please open a bug.

Andy

2009/5/11 Simone Gianni <simoneg@xxxxxxxxxx>:

Hi all,
since we have 1.6.4 in maven, we switched to it. Unfortunately however it 
seems like if there is a bug on 1.6.4 regarding getParameterNames on a
method signature.
In fact, under 1.6.3, a method sigature with zero parameters returned a zero 
length array on both getParameterNames and getParameterTypes and a zero
length array on getArgs on the corresponding joinpoint instance. On 1.6.4 
getParameterNames returns an array of length 1 (in my case, containing
"arg0"), while all the others still return a zero length array.

I suppose this is a bug, if none of you have a clear idea of why this
happens I can try build a simple testcase.

Simone

--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev


_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev






--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

Back to the top