RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Oct 3 20:28:56 UTC 2013
> 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
>
>
More information about the core-libs-dev
mailing list