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