It seems, the invokerLock is to protect any uses of the 'request' pointer that points to the field ThreadNode.currentInvoke, not to protect the saveGlobalRef() call itself. So that, we have a hole in synchronization that was nicely discovered by Severin G in the fix for bug:
https://bugs.openjdk.java.net/browse/JDK-8153711
Here are more places where the 'request' pointer is not protected with the invokerLock:
invoker_enableInvokeRequests()
invoker_isPending()
invoker_isEnabled().
In general, these are pretty simple or rare cases that do not harm much.
The function invoker_isPending() is not used at all.
https://bugs.openjdk.java.net/browse/JDK-8153711
Here are more places where the 'request' pointer is not protected with the invokerLock:
invoker_enableInvokeRequests()
invoker_isPending()
invoker_isEnabled().
In general, these are pretty simple or rare cases that do not harm much.
The function invoker_isPending() is not used at all.
- relates to
-
JDK-8181419 Race in jdwp invoker handling may lead to crashes or invalid results
-
- Resolved
-
-
JDK-8153711 [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command
-
- Resolved
-
-
JDK-8193879 Java debugger hangs on method invocation
-
- Resolved
-
-
JDK-8156498 more places in the invoke.c that need protection with the invokerLock
-
- Closed
-