IllegalMonitorStateException when creating an object

Question

I'm getting IllegalMonitorStateException when I'm trying to create an instance of an object. The code looks like the following:

public int signIn(parameters...)
{
  ...check some stuff...
  new Thread(... just a simple log here...).start();//IllegalMonitorStateException

  return result;
}

MORE INFO:
The actual application consists of 2 programs (C++ and java) interacting via JNI). The scenario in which I'm getting exception is as follows.

• The c++ program asks java to connect to a server. (this is a non blocking operation)
• Java program informs c++ about connection success. (in a new thread so that java can continue doing other tasks)
• When receiving connection success, c++ program asks java to login
• Exception occurs.

I should note that this exception only happens in this special scenario and if I call login sometime after connection success everything works fine.

What I've tried:

• In the beginning informing connection success was not in a new thread, but creating the thread did not solve the problem.
• The java login code had some synchronization stuff but removing them and replacing it with a simple log still produces the problem.

EDIT:
Here's the stacktrace:

Phoenix.client.ClientAPI.NativeInterface.NativeAPIEventListener.onConnectingFinished(Native Method) Phoenix.client.ClientAPI.NativeInterface.NativeAPIEventListener.access$000(NativeAPIEventListener.java:12) Phoenix.client.ClientAPI.NativeInterface.NativeAPIEventListener$1.run(NativeAPIEventListener.java:30) java.lang.Thread.run(Unknown Source)

Answer 1

I created a new thread in C++ code when java code called back into it This broke the jthread:java -> c++ -> java chain into jthread:java -> c++ and cthread:c++ -> java . This solved the problem I was facing. However I ran into a different problem which lead me into reading a bit of JNI documentation. Quoting JNI doc :

The JNI interface pointer (JNIEnv) is valid only in the current thread. Should another thread need to access the Java VM, it must first call AttachCurrentThread() to attach itself to the VM and obtain a JNI interface pointer . Once attached to the VM, a native thread works just like an ordinary Java thread running inside a native method. The native thread remains attached to the VM until it calls DetachCurrentThread() to detach itself.

So I guess I should've called AttachCurrentThread before calling back into java. However this does not exactly fit in the above description since the thread was not a native thread (it was a thread originally created in java code, could I call DetachCurrentThread afterwards?). I did not test this solution since I had to create a new thread other reasons too. But if I get a chance to try this out I'll confirm.