Repository navigation
"com.sun.jdi.InvalidStackFrameException occurred while retrieving value." when breaking on an exception #1955
Description
Description
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.
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?
Absolute-Arthur commentedon Nov 12, 2026
Yes, I can see the variables again, but not the ones I needed.
The "Language support for Java(TM) by Red Hat" extension does not log anything during the steps.
The "Debugger for Java" and "Test Runner for Java" extensions don't appear to offer any log (at least none in the Output window).
"Extension Host" in the Output window doesn't log anything during the steps.
issuelens commentedon Nov 12, 2026
Thanks for checking. The fact that stepping or resuming restores evaluation supports—but does not yet confirm—the stale/invalid stack-frame explanation; losing the needed context also means that workaround is not sufficient. There is no need to attach empty Output logs.
The older vscode-java-debug#767 remains related rather than a confirmed duplicate: it has the same exception-breakpoint failure, but its documented trigger was the target thread resuming, while this report specifically triggers after navigating away and back.
Could you still try the same caught-exception → open another Java file → return and evaluate sequence in a regular Java application (not a test)? That result would help distinguish test-launch integration from the shared Java debugger path.