-
Notifications
You must be signed in to change notification settings - Fork 28.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Unable to open 'Unknown Source'" if StackFrame.source is missing #20622
Comments
I'm still having this issue using the latest build as well as Insiders (updated today). VS Code: v.1.9.1 |
@Gama11 does the fix work for you? Namely vscode should simply not open the source if it is missing which would prevent the error. |
@isidorn Yes, it works if our debug adapter sends a stackframe like the one in the screenshot of my original post (one without a Our debug adapter used to send messages like this, where I just assumed that that was incorrect API usage / not supposed to work anyway - it always showed the path as Even though in 1.8.1, this didn't error, but it actually opened a |
@Gama11 thanks. Yes that is how it is supposed to work now. Adding verified label |
As I understand,
StackFrame.source
in the debug protocol is supposed to be optional (because there might not always be a source location available). However, starting with VSCode 1.9.0, a missingsource
causes the following error (after a pause request response, might happen elsewhere too):(btw: same thing with a
source
that is present, but has nopath
)At first glance, this makes it look like pausing didn't work. However, at a second glance, pausing and resuming still works fine, so it's mostly a cosmetic issue (that still might lead the user to think it's broken).
Here's what our debug adapter (Haxe Debug) sends:
This works fine (no error appears) in 1.8.1, which would make this a regression. The issue is still present in the latest Insider's build (1d17b45).
Other debug adapters seem to have the same issue, as suggested by this StackOverflow question regarding the same error message with ASP.NET.
Issue #4608 seems somewhat related to this.
The text was updated successfully, but these errors were encountered: