On Wed, 16 Jul 2025 01:46:29 GMT, Alex Menkov <[email protected]> wrote:
>> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal
>> with JDWP OPAQUE_FRAME error.
>>
>> Before virtual threads, OpaqueFrameException did not exist and these API
>> always threw NativeMethodException when JDWP OPAQUE_FRAME error was
>> returned. For virtual threads OpaqueFrameException was added to handle the
>> case where a virtual thread was not suspended at an event, so the JDI
>> implementation was updated to throw OpaqueFrameException if it detected that
>> a native method was not the cause. It turns out however that JVMTI (and
>> therefore JDWP) can return OPAQUE_FRAME error for reasons other than a
>> native method or the special virtual thread case, and for platform threads
>> we were incorrectly throwing NativeMethodException in these cases. This PR
>> fixes that. For platform threads we now only throw NativeMethodException if
>> a native method is detected, and otherwise throw OpaqueFrameException.
>>
>> The spec language is also being cleaned up to better align with JVMTI.
>> Rather than calling out all the reasons for OpaqueFrameException, a more
>> generic explanation is given.
>>
>> This is somewhat of a preliminary PR so I can get some feedback. I still
>> need to do a CR and complete testing.
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 412:
>
>> 410: if (meth.isNative()) {
>> 411: throw new NativeMethodException();
>> 412: }
>
>> Are you suggesting renaming the classes?
>
> No, I mean
>
> Suggestion:
>
> for (int i = 0; i < 2; i++) {
> StackFrame sf;
> try {
> sf = thread.frame(i);
> } catch (IndexOutOfBoundsException e) {
> // This should never happen, but we need to check for
> it.
> break;
> }
> Method meth = sf.location().method();
> if (meth.isNative()) {
> throw new NativeMethodException();
> }
Ok. I see now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2209062136
