[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp r
From:       Chris Plummer <cjplummer () openjdk ! org>
Date:       2022-09-27 20:59:46
Message-ID: biRiqacmlpj8ImZlFJr5porsJnrftpm8XVOn57s_JRU=.3294169a-0931-4ac5-8a8d-c26d81cbb570 () github ! com
[Download RAW message or body]

On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer <cjplummer@openjdk.org> wrote:

> There is a workaround we can do for \
> [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a \
> step over or step out is being done. This workaround can't be made to also work for \
> the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) \
>  "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. \
> Rather than the debug agent checking if it has enabled JVMTI single stepping, \
> instead it checks some fields in the ThreadNode that say if single stepping is \
> pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that \
> no StepEvent will occur at the same location and therefor the MethodEntryEvent \
> should not be deferred. So this limits the bug to only happening when doing a \
> STEP_INTO. "

Thanks Alex and Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/10091


[prev in list] [next in list] [prev in thread] [next in thread]