RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV

[Coleen Phillmore]

On 10/3/2013 7:01 PM, Daniel D. Daugherty wrote:
> On 10/3/13 4:56 PM, Coleen Phillmore wrote:
>>
>> Thanks Dan -
>>
>> On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote:
>>> > http://cr.openjdk.java.net/~coleenp/8025238/
>>>
>>> src/share/vm/classfile/javaClasses.cpp
>>>     1804   if (method == NULL) {
>>>     1805     // leave name and fileName null
>>>     1806 java_lang_StackTraceElement::set_lineNumber(element(), -1);
>>>         Is it possible to set the name and fileName to something?
>>>         A caller may not be expecting those to be NULL.
>>>
>>>         Also, holder->method_with_idnum(method_id) should be able to
>>>         search the previous class version list and find the obsolete
>>>         Method* that matches the 'method_id' value.
>>>
>>
>> We don't save the obsolete versions on the previous version list, 
>> only the emcp versions.  I just looked at the old code and that's 
>> always been the case.   So the method that has the method_idnum that 
>> isn't supposed to be found is an obsolete method.
>
> Clearly I've forgotten... thumbs up!

:)
Thanks,
Coleen

>
> Dan
>
>
>>
>> Coleen
>>
>>> src/share/vm/prims/jvmtiRedefineClasses.cpp
>>>     Better comment than the original.
>>>
>>> Dan
>>>
>>>
>>> On 10/3/13 12:02 PM, Coleen Phillimore wrote:
>>>> Summary: Redefined class in stack trace may not be found by 
>>>> method_idnum so handle null.
>>>>
>>>> This is a simple change.  I had another change to save the method 
>>>> name (as u2) in the backtrace, but it's not worth the extra 
>>>> footprint in backtraces for this rare case.
>>>>
>>>> The root problem was that we save method_idnum in the backtrace 
>>>> (u2) instead of Method* to avoid Method* from being redefined and 
>>>> deallocated.  I made a change to InstanceKlass::method_from_idnum() 
>>>> to return null rather than the last method in the list, which 
>>>> causes this crash. Dan and I went down the long rabbit-hole of why 
>>>> method_idnum is changed for obsolete methods and we think there's 
>>>> some cleanup and potential bugs in this area.  But this is not that 
>>>> change.  I'll file another bug to continue this investigation for 
>>>> jdk9 (or 8uN).
>>>>
>>>> Staffan created a test - am including core-libs for the review 
>>>> request.  Also tested with all of the vm testbase tests, mlvm 
>>>> tests, and java/lang/instrument tests.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238
>>>>
>>>> test case for jdk8 repository:
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>