The following test class SyncTest.java:

public class SyncTest
{
    public static Object lock = new Object();
    static int i = 0;
    void test() {
	synchronized(lock) {
	    i = 5;
	}
    }
}

produces these bytecodes for the method test():

--------
| test |
--------
010e  0000           access_flags:     
0110  000e           name:            "test"
0112  000b           descriptor:      "()V"
0114  0001           attributes_count: 1

0116  000c 00000049  Attribute "Code" len=73
011c  0001           max_stack:   1
011e  0003           max_locals:  3
0120  00000015       code_length: 21

0124  b2 0002           0 getstatic #2 "SyncTest" ("lock" "Ljava/lang/Object;")
0127  4c                3 astore_1
0128  2b                4 aload_1
0129  c2                5 monitorenter
012a  08                6 iconst_5
012b  b3 0003           7 putstatic #3 "SyncTest" ("i" "I")
012e  2b               10 aload_1
012f  c3               11 monitorexit
0130  a7 0008          12 goto 20
0133  4d               15 astore_2
0134  2b               16 aload_1
0135  c3               17 monitorexit
0136  2c               18 aload_2
0137  bf               19 athrow
0138  b1               20 return

0139  0002           exception_table_length: 2
      exception handler #1
013b  0006           start_pc:   6
013d  000c           end_pc:     12
013f  000f           handler_pc: 15
0141  0000           catch_type: 0 - Catches all exceptions.
      exception handler #2
0143  000f           start_pc:   15
0145  0012           end_pc:     18
0147  000f           handler_pc: 15
0149  0000           catch_type: 0 - Catches all exceptions.

==================================================================================

Notice that exception handler #2 defines an exception handler that designates itself as the handler for exceptions thrown within its own range.  Though this example cannot in of itself cause an IllegalMonitorStateException to be thrown, other examples using bytecode assemblers or JNI code can be manifactured to throw this exception.  For VMs that do not enforced structured locking (paired locks and unlocking), we can have a situation where the IllegalMonitorStateException is thrown while trying to execute the monitorexit bytecode if the object was not previously locked.  And based on the way the 1.4 javac generates code for the synthesized exception handler, we will end up catching the exception in exception handler #2 which then tries to do a monitorexit on the same object again.  This results in another IllegalMonitorStateException being thrown because the object is still not locked by the current thread.  This will happen perpetually resulting in what appears to be a hang.

This bug is similar to the case in CR 6271340, but this one does not involve a finally clause (i.e. no jsr/ret bytecodes), and can cause a real hang for some VM implementations.  Note that the VM spec says that VMs may, but are not required to, enforce structured locking.

###@###.### 2005-05-17 00:47:30 GMT