RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce

Chris Plummer cjplummer at openjdk.org
Tue Sep 20 22:20:06 UTC 2022


On Mon, 12 Sep 2022 21:52:31 GMT, Serguei Spitsyn <sspitsyn at 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. "
>
> test/jdk/com/sun/jdi/CLETest.java line 226:
> 
>> 224:                 System.out.println("TESTCASE #" + testcase + " FAILED" +
>> 225:                                    (testcase == 2 ? "(ignoring)" : "") +
>> 226:                                    ": too many events in EventSet: " + set.size());
> 
> The comment says there is a workaround in place allowing the 1st test case to pass.
> However, the 1st test case is marked as failed at the line 222 and the produced message says it is ignoring the 2nd test case. I'm confused. Do I miss anything?

testcase #2 is expected to fail, so that is why we do not set "testFailed = true" at line 222. However, if testcase #1 fails, we do want the overall test to fail, so in that case we set "testFailed = true" at line 222.

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

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


More information about the serviceability-dev mailing list