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.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply