You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"com.sun.jdi.InvalidStackFrameException occurred while retrieving value." when breaking on an exception #1955
When debugging an Exception in a test, if I go to a different Java file and back, I am no longer able to check variables' content.
Versions
OS : Windows 11 25H2
Visual Studio Code : 1.145.2
Java (used to launch the test) : 25
Test Runner for Java extension : 0.47.0
Debugger for Java extension : 0.60.0
To reproduce
Have a test that throws an Exception
Activate Breakpoint on Caught Exceptions
Debug the test
When the debugger pauses on the exception, either hover on a variable, or have a watched expression. You should see that it works fine.
Open another Java file
Go back to the breakpoint.
Actual outcome
On hover, the variable now displays "com.sun.jdi.InvalidStackFrameException occurred while retrieving value." If the watched expression is refreshed, it will show the same.
Expected outcome
It should show the variable content, just like it did in step 4.
Thanks for the clear reproduction. This looks like a test-debugging bug in the variable-evaluation path rather than test execution: the test extension launches a java debug session, while hover/watch values are resolved by the Java debugger.
A closely related older debugger report, vscode-java-debug#767, has the same exception-breakpoint/variable failure and traced it to an invalid cached stack frame after the target thread resumed. Your editor-navigation trigger is different, so there is not enough evidence to mark this as a duplicate; it may be a regression or another route to stale frame state.
As a temporary workaround, stepping once or resuming to a fresh breakpoint may establish a new valid frame. To narrow this down, could you attach the Java language server and Debugger for Java logs covering steps 4–6, and confirm whether the same sequence fails when debugging a regular Java application rather than a test?
Activity
issuelens commentedon Nov 10, 2026
Thanks for the clear reproduction. This looks like a test-debugging bug in the variable-evaluation path rather than test execution: the test extension launches a
javadebug session, while hover/watch values are resolved by the Java debugger.A closely related older debugger report, vscode-java-debug#767, has the same exception-breakpoint/variable failure and traced it to an invalid cached stack frame after the target thread resumed. Your editor-navigation trigger is different, so there is not enough evidence to mark this as a duplicate; it may be a regression or another route to stale frame state.
As a temporary workaround, stepping once or resuming to a fresh breakpoint may establish a new valid frame. To narrow this down, could you attach the Java language server and Debugger for Java logs covering steps 4–6, and confirm whether the same sequence fails when debugging a regular Java application rather than a test?