RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Oct 3 23:01:34 UTC 2013
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!
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
>>
>
More information about the core-libs-dev
mailing list