RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV
jeremymanson at google.com
Thu May 1 00:24:17 UTC 2014
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
oop java_lang_StackTraceElement::create(methodHandle method, int bci,
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());
fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, mp);
return create(mirror, method_id, method->constants()->version(), bci,
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?
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
More information about the hotspot-runtime-dev