If you use RedefineClasses on java.lang.Class in Update N (even without making any changes at all) it always causes an access violation during GC stage. It worked fine with all previous releases. Log attached.
I put together a JAR that crashes Update N JVM when run. On other JVMs it doesn't do anything. Source code is inside.
java -javaagent:jvm-bug-update-n.jar -jar jvm-bug-update-n.jar
Thanks for the test program. I used it on the Solaris SPARC bits for
the following releases:
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode)
java version "1.6.0_04-ea"
Java(TM) SE Runtime Environment (build 1.6.0_04-ea-b04)
Java HotSpot(TM) Client VM (build 10.0-b17, mixed mode)
java version "1.6.0_05-ea"
Java(TM) SE Runtime Environment (build 1.6.0_05-ea-b04)
Java HotSpot(TM) Client VM (build 1.6.0_05-ea-b04, mixed mode)
I was able to reproduce the crash with 6u5-B04 and that had me
puzzled until I remembered that the 6u5 project was using an older
VM snapshot until recently. The 6u5-B04 VM is based on the 6u4-B01
VM and will be updated to more recent bits in 6u5-B05.
I tested the snapshot that should be going into 6u5-B05 and it
does not have this crashing problem.
b06 features this fix and the testcase runs fine now.
Please find attached a core dump for Eugene's test driver. Maybe the fix didn't eventually make it into the 1.6.0_05-ea-b05?
This is not fixed in 1.6.0._05-ea-b05, it still crashes. Core dump attached.
> This is not fixed in 1.6.0._05-ea-b05, it still
> crashes. Core dump attached.
I should really stop trying to predict when fixes will make it out the
door during early access. :-) The 6u5 project is still using the older
VM snapshot (from 6u4-B01) as of 1.6.0_05-ea-b05. I don't have a
good idea yet when the 6u5 project will get more current, but I'll try
to remember to post again when more concrete info is available.
Thanks. As long as we are clear about that, it's fine. It was very confusing to not find it when expected.
Please ping this thread if the fix makes it in any of the next releases (not that we won't test it the moment it gets out, but still... :)
Okay,I nailed this down to a specific bug fix in 6u4-B02:
6530811 4/2 regression b08: SEGV in FastScanClosure::do_oop
The above bug was fixed in 6u4-B02 on 2007.07.16. I verified
that the bug does not reproduce with that fix in place and then
I verified that the bug does reproduce with the previous VM
Thanks for hs_err_pid log file. That will provide some clues.
Do you have a small test program that reproduces this crash?
I can try putting one together if I have time. Maybe later this week.
Basically you should register an Agent with premain, get the Instrumentation and then call redefineClasses() for java.lang.Class. If after that you call System.gc() it should fail. I started before to put the test together, but it needs to be packed in a jar, otherwise the agent won't work.
It might be good to run with -Xverify:all to see if anything pops up. It looks like the installation guide for the product suggests disabling the verifier which is going to making diagnosing bugs in the instrumentation code much harder to find. Using -Xbootclasspath/a can probably also be avoided but adding a Boot-Class-Path attribute to the agent's manifest.
I ran without -noverify and with -Xverify:all to the same result. Since the problem pops up only during GC stage I suspect that something is messed up in native code in redefineClasses(). Could it have something to do with the cache clearing on redefineClasses() introduced to java.lang.Class in Update N? Perhaps when it tries to do that for itself something is nulled and then accessed from native code?
Thanks for the Boot-Class-Path tip, I suspected its existence, but couldn't find it documented anywhere.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.