" Lock not owned by us " bug

Hi

I want to discuss about the "famous" bug "Lock not owned by us".

This bug was reported for the first time in this topic Bug

The last days I've investigated this issue and i want to share with you my findings for a few reasons :
- maybe i am on the wrong path
- maybe someone else will see the solution
- i want to solve this issue because it is annoying

I want to review the bug:

We have this block

synchronized (this) {
...
// call something that throws an exception
...
} // end synchronized

If an exception occurs in the middle of the block we have a panic error like this:
Lock not owned by us:java.util.Date00000001 12AA05D8 12AA05D0 00000000 00043E00 7FFFFE00 Debug stacktrace: org.jnode.vm.VmStackReader::debugStackTrace
, org.jnode.vm.VmStackReader::debugStackTrace
, org.jnode.shell.command.DateCommand::test12
, org.jnode.shell.command.DateCommand::
, org.jnode.shell.command.DateCommand::main
, org.jnode.vm.VmReflection::invoke
, java.lang.reflect.Method::invoke
, gnu.java.security.action.InvokeAction::run
, org.jnode.vm.VmAccessController::doPrivileged
, java.security.AccessController::doPrivileged
, org.jnode.shell.ThreadCommandInvoker$ThreadCommandRunner::run
, java.lang.Thread::run
, org.jnode.shell.CommandThread::run
, org.jnode.vm.scheduler.VmThread::runThread

So lets start with the beginning.

This is my class that I've used for test ( the date command )

public class DateCommand {

public static Help.Info HELP_INFO = new Help.Info("date", "prints the current date");

/**
* Sets up any instance variables and processes the command arguments.
*
* @param args
* The arguments to work with.
* @throws Exception
*/
public DateCommand(String[] args) throws Exception {
System.out.println(new Date());

test12();

}

public void test12() throws Exception {

Date lock = new Date();

synchronized (lock) {
test123();

}

}

public void test123() throws Exception {

throw new Exception("Test");

}

/**
* Displays the system date
*
* @param args
* No arguments.
* @throws Exception
*/
public static void main(String[] args) throws Exception {

new DateCommand(args);
}

}

This error appears in the class MonitorManager method public static void monitorExit(Object object)
This method basically removes the lock of the object .(It does a lot of things : decrement the counter and so on).

The lock of an object is kept in the header of the object. In this header the VM keeps the ID of the thread and the counter. Every time when monitorexist is called the counter is decrement. When the counter is 0 the ID of the thread is removed . This error appears because this method is called twice for my object . On the first call the ID of the thread is removed from the object header . When this method is called for the second time the condition that verifies if the ID of correct thread is in the header object fail and oopps error.

The method monitorexist is called when virtual machine reads a byetcode called monitorexit.
The parameter of the method are from the top of the stack.

Now let's look at bytecode of my method test12:

public void test12() throws java.lang.Exception;
Code:
0: new #38; //class java/util/Date
3: dup
4: invokespecial #40; //Method java/util/Date."":()V
7: astore_1
8: aload_1
9: dup
10: astore_2
11: monitorenter
12: aload_0
13: invokevirtual #54; //Method test123:()V
16: aload_2
17: monitorexit
18: goto 24
21: aload_2
22: monitorexit
23: athrow
24: return
Exception table:
from to target type
12 18 21 any
21 23 21 any

As you see we have 2 monitorexit in the bytecode. When i saw this for the first time i told myself: "This is the error : 2 monitorexist bytecode 2 calling of the method monitExit". But i was wrong . After reading carefully this code i realized that in a normal situation only one monitorexit bytecode is executed ( which is normal ).
At line 13 the method test123 is called. If no exception occurs the VM pushes the lock(or reference ??) on the stack and calls monitorexit (line 16,17). And then go to return. But if an exception occurs the VM will look in the exception table and tries to find a match for this exception and finds it (the fist line in exception table )12 18 21 any
So then it will execute the lines 21,22 which is a monitor exit. And it throws the exception (line 23) to the next method ( at least this is what i think). So this block from 21-23 is put by the compiler to be sure that when an exception occurs the monitor is exited. So in a normal situation only one monitorexit must be called.

Now what's happening in our code:

When the exception occurs at line 13 the VM tries to find a match and it finds it in the table exception (the fist line). Then go to line 21 and execute monitorexist and then throw the exception (line 23). Now it tries to find again a match in the same exception table of the same method and it finds it and go again to line 21 and go to monitor exit and => panic error. I've tracked this behavior in the method VMSystem.findThrowableHandler.

This is what i've found until now. Please shoot if I'm wrong. If you see the solution, I'll give you a beer.
I will continue my investigation and let you know.

Best regards
Andrei Dore