> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk
test/java/lang/instrument/RedefineMethodInBacktrace.sh
No comments.
test/java/lang/instrument/RedefineMethodInBacktraceApp.java
line 78: t.setDaemon(true);
Why make the target thread a daemon? Wouldn't it be a more
complete test to do Thread.join() of that thread just to
be sure that the target thread has finished (and is not
stuck)?
test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java
test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java
Nice sync logic with the test driver.
Thumbs up.
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
