(0.54) Adjust maxFrames in jvmtiInternalGetStackTrace for skipped frames #22393
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The JDWP frames command sets max_frame_count for JVMTI GetStackTrace based on the value returned by JVMTI GetFrameCount, and expects the number of frames filled by GetStackTrace to match that frame count. For JDK 20 and later, when debugging virtual threads, the first stack walk in jvmtiInternalGetStackTrace may filter out frames annotated with JvmtiMountTransition. These frames represent mount and unmount transitions for virtual threads and are not reported to the debugger. As a result, the frame count returned by GetStackTrace can be less than expected, causing JDWP to report a com.sun.jdi.InternalException: Unexpected JDWP Error: 113. This change increases maxFrames in the second stack walk by the number of frames skipped in the first pass. This ensures that after skipping mount transition frames, GetStackTrace can still return up to the original max_frame_count to JDWP, preserving consistency between GetFrameCount and GetStackTrace results and avoiding the above InternalException. Related: eclipse-openj9#22152 Signed-off-by: Babneet Singh <[email protected]>
Related to eclipse-openj9#22373 Signed-off-by: Peter Shipton <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The JDWP frames command sets max_frame_count for JVMTI GetStackTrace
based on the value returned by JVMTI GetFrameCount, and expects the
number of frames filled by GetStackTrace to match that frame count.
For JDK 20 and later, when debugging virtual threads, the first stack
walk in jvmtiInternalGetStackTrace may filter out frames annotated
with JvmtiMountTransition. These frames represent mount and unmount
transitions for virtual threads and are not reported to the debugger.
As a result, the frame count returned by GetStackTrace can be less than
expected, causing JDWP to report a
com.sun.jdi.InternalException: Unexpected JDWP Error: 113.
This change increases maxFrames in the second stack walk by the number
of frames skipped in the first pass. This ensures that after skipping
mount transition frames, GetStackTrace can still return up to the
original max_frame_count to JDWP, preserving consistency between
GetFrameCount and GetStackTrace results and avoiding the above
InternalException.
Related: #22152
Backport of #22373