RFR(xs): 8181419: Race in jdwp invoker handling may lead to crashes or invalid results

[Thomas Stüfe]

Ping... Anyone?

On Thu, Jun 1, 2017 at 2:18 PM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi all,
>
> please take a look at this proposed fix for a theoretical race in the jdwp
> library.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8181419
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
> 8181419-Race-in-jdwp-invoker-handling-may-lead-to-crashes-
> or-invalid-results/webrev.00/webrev/
>
> In short, this is an addition to Severin's fix to the jdwp invoke handling
> (https://bugs.openjdk.java.net/browse/JDK-8153711).
>
> We have a potential race condition where the delayed cleanup of the saved
> returnvalue object reference and the exception reference (released in
> deletePotentiallySavedGlobalRefs() ) may be overtaken by a new request
> which populates the thread request structure anew. If this happens,
> deletePotentiallySavedGlobalRefs() may actually release the return value
> / exception references of the follow up request, if that one was already
> processed.
>
> The solution I choose is safe and conservative. We still release both
> references, but use the locally saved JNI references. We just avoid
> accessing the thread local request structure after it has been cleared for
> reuse. This keeps timing and locking behaviour unchanged.
>
> I am currently running jtreg tests for com/sun/jdi on AIX and Linux.
>
> Kind Regards, Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170613/b3ee1968/attachment.html>