Hi Folks, may I please have a second reviewer?
Thank you! Kind Regards, Thomas On Tue, Jun 13, 2017 at 11:16 PM, serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > Hi Thomas, > > The fix looks great to me. > Thank you for identifying and fixing the problem! > > Thanks, > Serguei > > > > On 6/13/17 06:55, Thomas Stüfe wrote: > > Ping... Anyone? > > On Thu, Jun 1, 2017 at 2:18 PM, Thomas Stüfe <thomas.stu...@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 >> > > >
