One of the profiler vendors has a heap profiler that uses a combination of JVMTI and reflection to generate a heap dump. The attached hs_err_pid12844.log demonstrates a crash that they have encountered at one of their customer site's using 5.0u2.

Here's the stack from the fatal error log:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x4529b8] ;; symbolOopDesc::as_klass_external_name() const+0x18
V [libjvm.so+0x3717df] ;; Klass::external_name() const+0x1f
V [libjvm.so+0x241705] ;; InterpreterRuntime::create_klass_exception(JavaThread*, char*, oopDesc*)+0x55
j java.util.ArrayList.add(Ljava/lang/Object;)Z+26
j com.yourkit.runtime.RefVisitor.visit(Ljava/lang/Object;)V+220
v ~StubRoutines::call_stub
V [libjvm.so+0x24eafc] ;; JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x1bc
:

So it looks like the crash is happening when we try to throw an ArrayStore exception. I've exchanged mail with the submitter and elieve the issue is that JVMTI's GetClassFields is giving the agent some jfieldIDs for fields in the internal reflection classes. The result is that the application is getting references to the fields. Currently GetClassFields hides Throwable's backtrace field and we need to extend this to other fields. Any changes to GetClassFields needs to be done in conjunction with IterateOverReachableObjects as the field index reported to the agent in the heap iteration correspondds to array returned by GetClassFields.


###@###.### 2005-04-11 18:39:12 GMT