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

List:       openjdk-serviceability-dev
Subject:    RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp refer
From:       Chris Plummer <cjplummer () openjdk ! org>
Date:       2022-08-31 0:32:50
Message-ID: 8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55 () github ! com
[Download RAW message or body]

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. "

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

Commit messages:
 - Workaround for JDK-8292217 for step over.

Changes: https://git.openjdk.org/jdk/pull/10091/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10091&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293143
  Stats: 17 lines in 2 files changed: 10 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10091.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10091/head:pull/10091

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


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