Thank you Serguei! ..Thomas
On Sun 18. Jun 2017 at 00:42, serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > Hi Thomas, > > An update on this. > > I ran the nsk.jdi and jtreg jdk.jdi tests on Linux-x64. > The results are pretty good. > One jtreg test failed: > com/sun/jdi/LineNumberInfo.java: Test javac regressions in the generation > of line number info > > This failure seems to be unrelated to your fix as it is about incorrect > line number information. > > Thanks, > Serguei > > > > > On 6/15/17 11:00, serguei.spit...@oracle.com wrote: > > Hi Thomas, > > Sure. > > > I'll also run some internal jdi tests. > > Thanks, > Serguei > > > On 6/13/17 21:17, Thomas Stüfe wrote: > > Hi Sergey, > > thank you for the review! > > I ran jdi jtreg tests on both AIX and Linux x64, I had some issues but > they seemed preexisting (same issues without my patch). Could you please > also run tests you think are necessary on your platforms? Thanks! > > best Regards, Thomas > > On Wed, Jun 14, 2017 at 1:36 AM, serguei.spit...@oracle.com < > serguei.spit...@oracle.com> wrote: > >> On 6/13/17 14:16, serguei.spit...@oracle.com wrote: >> >> Hi Thomas, >> >> The fix looks great to me. >> >> >> Forgot to say that the copyright comment need an update. >> >> Thanks, >> Serguei >> >> >> 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 >>> >> >> >> >> > >
