Community
Participate
Working Groups
Created attachment 100055 [details] Core dump. Core file attached. Spring 2.5.4. Happens on startup when I have the following in my spring config: <jms:listener-container connection-factory="jmsConnectionFactory"> <jms:listener destination="foo" ref="fooMessageListener" /> <jms:listener destination="bar" ref="barMessageListener" /> </jms:listener-container> Happens with activemq-all-5.0.0.jar and again with activemq-all-5.1.0.jar.
The NPE here is when comparing parameters sets between two methods to see if they match - the names have already matched. I suspect it is a method accessed via reflection that is returning null rather than a bcel accessed one since we are in the LTW environment.
Are you able to confirm if these are regressions - did everything used to work fine with this code and Spring2.5.3/AspectJ1.5.4? I'm going to ask the same in the other bug of yours :)
(In reply to comment #2) > Are you able to confirm if these are regressions - did everything used to work > fine with this code and Spring2.5.3/AspectJ1.5.4? I'm going to ask the same in > the other bug of yours :) I don't believe so. I was on 2.5.3/1.5.4 and switched from JBoss to straight Tomcat. At the same time I switched from the 2.5.3 spring-agent to the 2.5.3 spring-tomcat-weaver. This is when the core dumps first manifested, on 2.5.3/1.5.4, so I upgraded everything to 2.5.4/1.6.0. A spring-tomcat-weaver message about a missing aop.xml disappeared on the upgrade, but otherwise the cores persisted. This is when I tried to upgrade ActiveMQ from 5.0.0 to 5.1.0, but again no change. I'll CC this to bug #231945 as well. :)
I've built 1.6.0 source jars and can debug into this now. Not sure if this is of any further help, but all the local variables are null on the matches call when the error is raised: aCandidateMatch null candidateMatchImpl null myParameterTypes null candidateParameterTypes null I might need some guidance on what to step through and what to look for, but if I can be of any further help let me know.
Was aCandidateMatch definetly null? Since at line 865 and 867 prior to the failure we access it (the core dump showed a crash at line 868). if you have a breakpoint at the failure line, you could look at the state of the associated JoinPointSignatureIterator that is a little further up the stack - the 'signaturesOfMember' instance field in there will tell us which method in which type is having trouble.
still getting this problem Ian?
(In reply to comment #6) > still getting this problem Ian? We've stopped using JMS in our trunk so I can't test this one off hand. I'll try to get an old revision setup from when this bug was manifesting. With the holidays it may take me a bit to get to it so bear with me...
Dont struggle to recreate it if it isn't holding you up at the moment - but I will leave this open so we know there is still an issue here.
I've stumbled on the same NPE here, in a completely different context. As it seemed to happen due to the upgrade from 1.6.2 to 1.6.4, I investigated it quite deeply by stepping into a lot of code, before finding out it actually happened with 1.6.2 as well (and with 1.6.5). It's a change in the weaved classes that triggered the bug (probably related to the order in which the classes / methods are processed). I'm not sure I can package a test case without packaging the entire (and quite large) application, but maybe what I have found out while stepping into the application start will be enough. Otherwise I'll try to create a test case out of our application by removing as much as I can. In a nutshell: it's a recursive call problem. While inside BcelMethod.unpackGenericSignature(), at line 531 (in 1.6.5) genericReturnType = BcelGenericSignatureToTypeXConverter.typeSignature2TypeX(returnTypeSignature, formals, bcelObjectType.getWorld()); another class resolution is triggered, etc., which after a long stack ends up in ResolvedMemberImpl.matches() at line 924 UnresolvedType[] myParameterTypes = getGenericParameterTypes(); on the same BcelMethod, and BcelMethod.getGenericParameterTypes() calls again BcelMethod.unpackGenericSignature() which returns directly since bitflags & UNPACKED_GENERIC_SIGNATURE != 0 (the unpacking is marked as done while it is actually still being done). That's why BcelMethod.getGenericParameterTypes() returns null and we get a NPE in ResolvedMemberImpl.matches() at line 926 when using myParameterTypes.length. I'm attaching my own dump, with the stack trace annotated for the context (look for comments with "Note on the above line").
Created attachment 142010 [details] Dump with an annotated stack trace
unsetting the target field which is currently set for something already released
