- A Concurrent Affair - https://www.concurrentaffair.org -

Problems With Instrumented Runtime

I’m running tests again that use a Java runtime in which synchronized blocks have been instrumented with logging calls. This is pretty much the minimum capability I need. Georges does it too.

I’m getting both a HotSpot Virtual Machine error and an exception in the JPDA thread monitor I wrote:

# An unexpected error has been detected by HotSpot Virtual Machine:
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d728200, pid=5864, tid=5844
# V  [jvm.dll+0xe8200]

I don’t know if the two have anything to do with each other, but the exception I got in the thread monitor is due to a null reference where I’m expecting a ThreadReference. This means a synchronized block entry has been logged but Thread.currentThread() returns null. Fantastic. Again I’m finding I’m doing things too early during VM initialization.

I think it will be very hard to distinguish at instrumentation time which places cause this behavior. That means I probably have to instrument them all and decide at runtime. Now, there are two options: I can ignore the event, which is probably ok since the Java VM clearly hasn’t been set up completely yet; or I can report and special-case it, which might get hairy on the thread monitor side.


I’ve started to go the special-case route (I’m trying to be thorough: if something can be reported, it should be — it can always be ignored later), and I’ve noticed that the HotSpot VM error only seems to occur when the JPDA thread monitor is attached. If I run the slave program without the monitor, the log functions do get called, but no error occurs. Quite peculiar.

[1] [2]Share [3]