Details
-
Bug
-
Resolution: Fixed
-
P3
-
8u152, 9, 10
-
b13
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8188624 | 8u172 | Thomas Stuefe | P3 | Resolved | Fixed | b01 |
JDK-8190626 | 8u171 | Thomas Stuefe | P3 | Resolved | Fixed | b01 |
JDK-8186555 | 8u162 | Thomas Stuefe | P3 | Resolved | Fixed | b01 |
JDK-8186031 | emb-8u171 | Unassigned | P3 | Closed | Won't Fix | b01 |
Description
At the end of JDWP invoke handling we want to release all global references the invoke may have created. This may also include the return value object ref, if return value was an object, and the exception ref, if an exception was thrown.
Both return value object ref and exception ref need to be kept alive during the sending of the JDWP answer packet, because during sending references are translated into objectIDs and both references have to be not yet collected to do that.
The sending of the answer packet must happen outside the invokerLock, to minimize the chance for deadlocks.
Once sending is done, we enter the invokerLock again and clean up return value object ref and exception object ref.
Pseudocode:
{code}
invoker_completeInvokeRequest()
enter invokerLock;
A reset Thread's InvokeRequest structure:
request->pending = JNI_FALSE;
request->started = JNI_FALSE;
request->available = JNI_TRUE; /* For next time around */
retrieve exception ref and return value object ref from InvokeRequest structure
B leave invokerLock();
C send answer packet containing exception ref and return value object ref, both will be resolved to objectIDs.
enter invokerLock;
D release exception ref and return value object ref *by accessing the thread request structure*
leave invokerLock();
{code}
At (A) we clear the InvokeRequest structure of the thread for the next invoke request.
At (B) we leave lock protection and from now on a new invoke request may be filled in immediately by the JDWP listener thread.
At (D) we release the references by taking them from the thread request structure. I think this is wrong, because the request structure may already have been filled by another completed invoke request, whose return values we now delete. If that request answer is sent after ours, it will encounter invalid object references.
==========
IMHO there are several ways to fix this:
1) move the "request->available = JNI_TRUE;" down after the answer packet was sent. But this opens the possibility for deadlocks, because while this (potentially longish) IO happens, no other invoke request can be served.
2) We do not need to access the thread request structure to release the object references contained in it. Just use local variables to keep the object references to release.
3) We also could split outStream_writeObjectRef() into two parts, one which gets the objectID, one which writes the objectID. Then, we could get the objectIDs for exception ref and return value object ref before (B), release them also before (B), and just send back the objectIDs in C.
I favour (2) though, because it is a less invasive change.
Attachments
Issue Links
- backported by
-
JDK-8186555 Race in jdwp invoker handling may lead to crashes or invalid results
-
- Resolved
-
-
JDK-8188624 Race in jdwp invoker handling may lead to crashes or invalid results
-
- Resolved
-
-
JDK-8190626 Race in jdwp invoker handling may lead to crashes or invalid results
-
- Resolved
-
-
JDK-8186031 Race in jdwp invoker handling may lead to crashes or invalid results
-
- Closed
-
- relates to
-
JDK-8153711 [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command
-
- Resolved
-
-
JDK-8154529 some places in the invoke.c that use InvokeRequest* not protected with invokerLock
-
- Resolved
-
-
JDK-8193879 Java debugger hangs on method invocation
-
- Resolved
-
-
JDK-8176567 nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10
-
- Resolved
-