FULL PRODUCT VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Microsoft Visual Studio 2008 reports the issue, when attached to java.exe resp. jawaw.exe

A DESCRIPTION OF THE PROBLEM :
When debugging the C++ part of my JNI application occasionally an error

First-chance exception at 0x6d801017 in javaw.exe: 0xC0000005: Access violation writing location 0x003e0d00.

pops up in Visual Studio.
There's no usable call stack, and it happens occasionally only. Ignoring does not seem to hurt anything.

By reducing everything suspicious and trying to find the trigger for this access violation, I noticed it does not have anything to do with my native code. I don't need to reference any native method or even load my library at all.
But it seems to be related to Garbage Collection.

My test now simply creates some objects ( java.lang.Long is sufficient )
and forces runtime to finalize/gc them immediately.
1000 such objects produce about 20 access violations.

When running the test without debugging environment, all is fine.

BTW: When trapping this error, Visual Studio is able to show and edit the mentioned memory location.



THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run sample code above and inspect Visual Studio's immediate window after attaching to the java.exe process

ERROR MESSAGES/STACK TRACES THAT OCCUR :
First-chance exception at 0x6d801017 in java.exe: 0xC0000005: Access violation writing location 0x003e0700.
First-chance exception at 0x6d801017 in java.exe: 0xC0000005: Access violation writing location 0x003e0c00.
First-chance exception at 0x6d801017 in java.exe: 0xC0000005: Access violation writing location 0x003e0000.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class TestGCException {
public static void main(String[] args) {
TestGCOnly();
}
final static Runtime rt=Runtime.getRuntime();
static String runFinalize() { // return value intended to update e.g. in a Expression window
rt.runFinalization();
rt.gc();
return "Finalized at " +
(new java.util.Date (System.currentTimeMillis()));
}
 
public static void TestGCOnly() {
try {
System.out.print("Press <Enter> after Attach to process javaw.exe :");
System.in.read();
} catch(java.io.IOException iox){};

System.out.println("Starting Test");
try {
int loops = 5;
while (loops-- > 0) {
for (int i = 0; i < 100; i++) {
{
Long l = new Long(123456789);
Long l2 = -l;
l = l2 * 2; // just to avoid "never read" warnings in Eclipse
}
Thread.sleep(3);
runFinalize();
}
System.out.print(".");
}
} catch (InterruptedException e) {
System.out.print("!");
}
System.out.println(" Done");
}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
VisualStudio can be configured to not trap on this error. But when debugging my own native code ( in a jni project) this is not intended.

Very annoying to always click ignore when this error pops up (and to immediately distinguish it from something (more) relevant).