Skip to main content

EXCEPTION ACCESS VIOLATION on RedefineClasses

12 replies [Last post]
ekabanov
Offline
Joined: 2006-04-04
Points: 0

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.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ekabanov
Offline
Joined: 2006-04-04
Points: 0

I put together a JAR that crashes Update N JVM when run. On other JVMs it doesn't do anything. Source code is inside.

To run:
java -javaagent:jvm-bug-update-n.jar -jar jvm-bug-update-n.jar

dcubed
Offline
Joined: 2007-10-10
Points: 0

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)

and

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.

mr_dronski
Offline
Joined: 2003-06-11
Points: 0

b06 features this fix and the testcase runs fine now.

mr_dronski
Offline
Joined: 2003-06-11
Points: 0

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?

mr_dronski
Offline
Joined: 2003-06-11
Points: 0

This is not fixed in 1.6.0._05-ea-b05, it still crashes. Core dump attached.

dcubed
Offline
Joined: 2007-10-10
Points: 0

> 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.

mr_dronski
Offline
Joined: 2003-06-11
Points: 0

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... :)

dcubed
Offline
Joined: 2007-10-10
Points: 0

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
(from 2007.07.13).

dcubed
Offline
Joined: 2007-10-10
Points: 0

Thanks for hs_err_pid log file. That will provide some clues.
Do you have a small test program that reproduces this crash?

ekabanov
Offline
Joined: 2006-04-04
Points: 0

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.

alanb
Offline
Joined: 2005-08-08
Points: 0

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.

ekabanov
Offline
Joined: 2006-04-04
Points: 0

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.