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.phillim...@oracle.com <mailto:coleen.phillim...@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
