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

[Coleen Phillmore]

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.

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
>