Community
Participate
Working Groups
Created attachment 165355 [details] production stack trace Null pointer exceptions under load after upgrading from AspectJ 1.6.4 to 1.6.8. Using Spring 2.5.6. A full stack trace and Spring context file are attached. Caused by: java.lang.NullPointerException at org.aspectj.weaver.World.resolve(World.java:265) at org.aspectj.weaver.World.resolve(World.java:209) at org.aspectj.weaver.World.resolve(World.java:244) at org.aspectj.weaver.TypeFactory.createParameterizedType(TypeFactory.java:45) at org.aspectj.weaver.reflect.JavaLangTypeToResolvedTypeConverter.fromType(JavaLangTypeToResolvedTypeConverter.java:75) at org.aspectj.weaver.reflect.JavaLangTypeToResolvedTypeConverter.fromTypes(JavaLangTypeToResolvedTypeConverter.java:123) at org.aspectj.weaver.reflect.Java15ReflectionBasedReferenceTypeDelegate.getDeclaredInterfaces(Java15ReflectionBasedReferenceTypeDelegate.java:127) at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:622) at org.aspectj.weaver.ResolvedType$2.get(ResolvedType.java:304) at org.aspectj.weaver.ResolvedType$2.get(ResolvedType.java:300) at org.aspectj.weaver.ResolvedType$SuperInterfaceWalker.hasNext(ResolvedType.java:2171) at org.aspectj.weaver.Iterators$6.hasNext(Iterators.java:288) at org.aspectj.weaver.patterns.KindedPointcut.fastMatch(KindedPointcut.java:128) at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.couldMatchJoinPointsInType(PointcutExpressionImpl.java:82) at org.springframework.aop.aspectj.AspectJExpressionPointcut.matches(AspectJExpressionPointcut.java:235) at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:195) at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:250)
Created attachment 165356 [details] sample spring context file
it appears that here: JavaLangTypeToResolvedTypeConverter.fromType(Type t) we compute some an array of type parameters in order to call TypeFactory.createParameterizedType and the array we create has null entries. I can't see an obvious route through that would create a null entry. I imagine you can't share with me the failing code can you? If I created a patch for 1.6.8 that told us about the types involved when the failures occur, could you apply that (update the aspectjweaver.jar) and let me know the outcome?
I've patched a weaver - it is here: http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectjweaver_309741_1.jar This should throw an exception at the initial time the problem occurs: throw new IllegalStateException( "Parameterized type problem. basetype=" + baseType + " arguments=" + sb.toString() + " ss=" + ss); which will at least tell us the parameterization that is a problem - hopefully that will help diagnose.
We finally ran a load test with the patched aspectjweaver jar and got the attached stack traces.
Created attachment 175502 [details] stack traces with debugging version of aspectjweaver jar
The trace includes 3 interesting things: Caused by: java.lang.IllegalStateException: Parameterized type problem. basetype=java.lang.Comparable arguments=null ss=java.lang.Comparable<E> org.aspectj.weaver.reflect.JavaLangTypeToResolvedTypeConverter.fromType(JavaLangTypeToResolvedTypeConverter.java:83) Caused by: java.lang.IllegalStateException: Why set this late? org.aspectj.weaver.TypeVariable.setAdditionalInterfaceBounds(TypeVariable.java:217 Caused by: java.lang.IllegalStateException: Parameterized type problem. basetype=java.lang.Enum arguments=null ss=java.lang.Enum<E> org.aspectj.weaver.reflect.JavaLangTypeToResolvedTypeConverter.fromType(JavaLangTypeToResolvedTypeConverter.java:83) Interestingly, correct handling for Comparable is something I was just working on under 278496 (and Enum has similar characteristics). In that bug I observed that should Comparable ever get thrown out of the weavers type world (due to memory constraints) then when it is recovered it won't be quite the same as before. The fact that this issue occurs 'under load' suggests it could be related to that problem. If you are feeling adventurous, you could try todays dev build of the weaver: http://download.eclipse.org/tools/aspectj/dev/aspectjweaver-1.6.10.20100806.jar which includes the latest changes related to 278496.
Created attachment 183441 [details] stack trace with aspectj 1.6.10 RC1
Created attachment 183499 [details] Patch for weaver Still a bit of guesswork without a failing sample. But we do seem to be moving forward as the older problems have gone. I've attached here a replacement for the TypeVariable class - this new version will not throw the exception that you show in the log, but instead just mark the type as needing re-resolution due to bounds apparently being changed. There are a couple of other things I could try, but this is the most simple. To apply this just unpack it and update the weaver jar jar -xvf patch.zip jar -uvf pathto/aspectjweaver.jar org
Created attachment 183716 [details] stack trace from aspectj 1.6.10 + patch applied the patch and this exception showed up quickly in load test.
After refactoring our code to eliminate the <util:constant> bean and prototype beans, we are deployed in production with aspectj 1.6.10. I can attach a sample context file and code if you want to pursue this issue.
Hi Scott, Glad to hear you have gotten something working now. I'm frustrated we haven't fixed this issue though - things like this I can't recreate myself as so tricky to resolve. If you could attach something to help me nail it, that would be great. I imagine if you give me a sample I can stress it memory wise and maybe cause something to happen...
unsetting the target field which is currently set for something already released
