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

[Coleen Phillimore]

We didn't file any bugs because I don't remember finding anything 
specific, other than "gosh that code is scary" and "I wish we didn't 
have to do this".

If you find a null 'm' below and call m->print() is the method "obsolete"?

Coleen

On 4/30/14, 8:24 PM, Jeremy Manson wrote:
> Did the new bugs get filed for this?
>
> I'm triggering this check with a redefined class (from the 
> bootclasspath, if that matters).  To investigate it a little, I 
> instrumented StackTraceElement::create thus:
>
> oop java_lang_StackTraceElement::create(methodHandle method, int bci, 
> TRAPS) {
>   Handle mirror (THREAD, method->method_holder()->java_mirror());
>   int method_id = method->method_idnum();
>
>   InstanceKlass* holder = method->method_holder();
>   Method* m = holder->method_with_idnum(method_id);
>   Method* mp = holder->find_method(method->name(), method->signature());
>   method->print_name();
>   fprintf(stderr, " method = %p id = %d method' = %p \n", m, 
> method_id, mp);
>   return create(mirror, method_id, method->constants()->version(), 
> bci, THREAD);
> }
>
> m is null, and mp isn't.  method->print_name works fine.  This makes 
> me feel that the idnum array is out of date somehow.  Before I go down 
> the rabbit hole and try to figure out why that is, does someone else 
> know why?
>
> Thanks!
>
> Jeremy
>
>
>
> On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore 
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> 
> 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/
>     <http://cr.openjdk.java.net/%7Ecoleenp/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
>     <http://cr.openjdk.java.net/%7Ecoleenp/8025238_jdk>
>
>     Thanks,
>     Coleen
>
>