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

[Jeremy Manson]

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> 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
>