Disable "Unable to open file" during debug

[DigiAngel]

So I'm creating a very simple c++ app for learning on Ubuntu using c++ and gdb:

#include <iostream>

using namespace std;

int main ()
{
    int score = 0;
    cout << "Enter an integer score between 0 and 100." << endl;
    cin >> score;

    if(score >= 90 && score <= 100)
    {
        cout << "Awesome!" << endl;
    }
    if(score >= 80 && score <= 89)
    {
        cout << "Well Done." << endl;
    }
    if(score >= 70 && score <= 79)
    {
        cout <<  "Average." << endl;
    }
    if(score >= 60 && score <= 69)
    {
        cout << "Bummer." << endl;
    }
    if(score >= 0 && score <= 59)
    {
        cout << "Sad Times." << endl;
    }

    return 0;
}

When pausing and stepping into/over I have to hit cancel each time for things like this:

Is there a way to disable these so I can step through the program? Thank you.

[pieandcakes]

@DigiAngel That would probably be a VSCode question. We send back a path that VSCode can't find (which for these is probably the case).

[DigiAngel]

Brilliant thanks...I'll close and approve from that end.

[DigiAngel]

So they say it's you...so...now what :)

microsoft/vscode#28433

[ramya-rao-a]

The question from me (from VS Code) is are those files absolutely relevant for the user to debug a simple code sample as above. This can be answered by the extension owners.

If it is absolutely required, then the current behavior is right. As in the extension requests VS Code to open a file that VS Code cannot find and communicates the same to the user using the current notification model.

If the notification model is what is bothersome, then you can pitch in here: microsoft/vscode#22388 where we talk about improvements to the notification model.

[sean-mcmanus]

Oh, yeah, I've hit this "can't open file" thing. I assumed it was "by design". I think the popup model is annoying because it requires manual clicking to get rid of. Outputting the error to the Output window is less intrusive.

[pieandcakes]

@ramya-rao-a These file don't exist on the users machine. The users are debugging in to library code that they may (but most likely) don't have. In that instance, I think @DigiAngel wants an option to stop getting notified that the files can't be found. I think this is a good feature per debug session or per instance of file but if the user starts another debug session, they should be notified once just in case its a file they care about.

[pieandcakes]

@sean-mcmanus the notification is by VS Code. Changing it to the output window may be better but I know people who have the debug Console up and not the Output window so it might be invisible to the user which isn't a good experience either.

[ramya-rao-a]

cc @isidorn for thoughts on #811 (comment)

[isidorn]

@pieandcakes if the file is not available please send the presentationHint of deemphasize and vscode shuold not automatically show it (note that I have only now pushed this change to vscode so you can pick it up in vscode insiders)

[DigiAngel]

Thanks for the chatter and discussion around this...really appreciate it.

[pieandcakes]

@isidorn I can see what we can do. Which response does this lie in?

The problem is that we don't know if it should be available or not. We as the debugger don't know if its user or library code in C++ so we send back every path. If the user is doing remote debugging and didn't setup source mapping correctly, we do want those errors but with library code we don't. The simplest way would be for the user to decide which warnings they want to see again versus the debugger trying to figure it out and getting it wrong.

[isidorn]

@pieandcakes you can have the presentationHint as part of the StackFrame or the Source

If we want to give more control to the user to choose which warnings to see that would be a feature request on the vscode (which we can look into if more users ask for this or we accept PRs of course)

[DigiAngel]

Any movement on this? Thank you.

[pieandcakes]

@DigiAngel It looks like we need to make a feature request with VSCode. @isidorn 's suggestion of presentationHint would not work in our scenario because as far as I know, gdb doesn't tell me the difference between user and library code.

[DigiAngel]

@pieandcakes Thank you....is there something I can do on my end? And maybe just a path check would suffice to determine user code?

[pieandcakes]

I guess to get rid of the message, you could download glibc source but I don't think that's a good fix. I need to do some searching (or if you want to, that would help) on whether there is a way to tell from gdb if code is from a library or not. If there is, then we might be able to take advantage of @isidorn 's suggestion but from my quick look, I didn't see anything

[DigiAngel]

Yea I looked and didn't find anything...even this: gdb-dashboard will display the error. So it looks like a suppression option is the route to go. I wouldn't complain if it was just a popup, but it completely halts debugging until you hit Create or Cancel each step. Thank you.

[CTimmerman]

I'd put those annoying interface-hiding messages in their own tab.

[ntphx]

@pieandcakes

This issue still persists in vscode 1.15.1 with c/c++-tools 0.12.3.
Has there been any progress on this issue, or, is there some form of workaround available?

[pieandcakes]

@radiowest I have not had time to investigate a solution.

[anselanza]

This is causing troubles for me, too. I have downloaded glibc source but not entirely sure where to symlink it. Anybody at least have success doing that as a workaround?

[ntphx]

Updating to the latest version of VSCode fixed this problem for me. From: Stephen Buchanan <notifications@github.com> Reply-To: Microsoft/vscode-cpptools <reply@reply.github.com> Date: Monday, 8 January 2018 at 12:12 To: Microsoft/vscode-cpptools <vscode-cpptools@noreply.github.com> Cc: radiowest <bramvandecapelle@gmail.com>, Mention <mention@noreply.github.com> Subject: Re: [Microsoft/vscode-cpptools] Disable "Unable to open file" during debug (#811) This is causing troubles for me, too. I have downloaded glibc source but not entirely sure where to symlink it. Anybody at least have success doing that as a workaround? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jharveyb]

I have the same problem with the most recent versions of both the standard and Insider build.

glibc-source is on the path /usr/src/glibc/glibc-2.26/ for me and I would be happy to symlink it somewhere to resolve this if possible.

Edit: Resolved this by following what ChanJuiHuang did to resolve the same issue, as explained in #1094

Specifically, the error I received was that a file couldn't be found on the path "file:///build/glibc-8C7Cr9/glibc-2.26/.../..." - creating /build/glibc-8C7Cr9/, and making a symlink between /usr/src/glibc/glibc-2.26 and /build/glibc-8C7Cr9/glibc-2.26 fixed this.

The fix has persisted across restarts of VSC, though I haven't tested across restarts of the machine. Other similar issues have mentioned error messages with a similar format path, so it seems that the path is generated on install and then not updated.

Another potential solution is to display functions in the call stack debug window in reverse alphabetical order instead of alphabetical order, so that main (or some other user-defined function) is the first entry and builtin functions are last. Didn't see a user-controllable setting for this though.

@anselanza @DigiAngel this should work.

[anselanza]

I solved my issues by laboriously going through each third-party library linked in my project and adding their paths (under includePath) to c_ppp_properties.json

[Trass3r]

In the meantime it could be resolved by setting Source.PresentationHintValue.Deemphasize.

[aliyyousuff]

In the meantime it could be resolved by setting Source.PresentationHintValue.Deemphasize.

How could it be done? Could you please explain more?

[Trass3r]

This was referring to an internal fix until disassembly debugging is ready.
If you want to use that you'd have to compile MIEngine yourself and put the files into ~/.vscode-server/extensions/ms-vscode.cpptools-*/debugAdapters/bin.

[Xiaohong-Deng]

Can this problem be resolved if the files that are unable to be opened are in C standard library?

[Trass3r]

Doesn't matter where they come from.
Will be fixed with microsoft/MIEngine#1038.

[github-actions]

This issue has been closed automatically because it's labeled as 'external'.

[default-writer]

gcc flag -save-temps autogenerates all .S files required

---- tasks.json ----

{
    "tasks": [
        {
            "type": "cppbuild",
            "label": "C/C++: gcc build active file",
            "command": "/usr/bin/gcc",
            "args": [ 
                "-g",
                "-save-temps",
                "*.c",
                "-o",
                "${fileDirname}/lisp"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "detail": "Task generated by Debugger."
        }
    ],
    "version": "2.0.0"
}

[MartinMajewski]

I'm using CMake to build and debug my project remotely on a RaspberryPi with the Remote-SSH plugin.
My application reads from a serial port in another thread.

Sometimes it takes several minutes. Sometimes it breaks immediately with the messages:

Unable to open 'pthread_join_common.c': Unable to read file 'vscode-remote://ssh-remote+devpi64/build/glibc-pfQmxL/glibc-2.28/nptl/pthread_join_common.c' (Error: Unable to resolve non-existing file 'vscode-remote://ssh-remote+devpi64/build/glibc-pfQmxL/glibc-2.28/nptl/pthread_join_common.c').

and/or

Unable to open 'read.c': Unable to read file 'vscode-remote://ssh-remote+devpi64/build/glibc-pfQmxL/glibc-2.28/sysdeps/unix/sysv/linux/read.c' (Error: Unable to resolve non-existing file 'vscode-remote://ssh-remote+devpi64/build/glibc-pfQmxL/glibc-2.28/sysdeps/unix/sysv/linux/read.c').

The problem is that after these messages appear, the variable lookup does not work anymore correctly, nor do I get any output on the terminal. I have to press "Continue" until the process ends - so I have to provide an invariant that shuts the thread and main process down eventually.

This is a very unpleasant and undesired behavior without a fix, which renders VSC unusable for more than small "hello world" projects, unfortunately.

Is there a workaround for CMake? I don't have any launch.json or task.json files.

[trogne]

On vscode and wsl (ubuntu).
The only thing that work for me is to make a symlink, like that :

sudo cp /usr/src/glibc/glibc-2.31 /build/glibc-eX1tMB/

sudo mkdir /build
sudo ln -s /usr/src/glibc /build/glibc-eX1tMB

Simply using source map was not working :

"sourceFileMap": {
	"/build/glibc-eX1tMB": "/usr/src/glibc/"
},

[bsekura]

I'm not sure why this is closed, it is not fixed at all.

Fresh Ubuntu 20.04 install, fresh vscode install.
Stepping over results in:

[diyessi]

I started getting it a day or two ago for futex-internal.h with the last vsc update, which is from two threads in a pthread wait; not the thread involved in debugging, so there's absolutely no reason anything like this should be showing up.

[evdenaxas]

Not sure why this is closed. Started happening after I updated to latest vscode version on pause.c while debugging.

[microelec]

I started getting it a day or two ago for futex-internal.h with the last vsc update, which is from two threads in a pthread wait; not the thread involved in debugging, so there's absolutely no reason anything like this should be showing up.

I have same issue too. It is really a terrible thing to do debugging step by step with this problem. Fortunately, I happen to get rid of it by enable thread non-stop.
Just add following configuration in .gdbinit
set target-async 1
set pagination off
set non-stop on

[bim-ba]

Im getting the same error

But when i added "-std=c++20" to my tasks.json thats fixed my problem.

"args": [
    "-Wall",
--> "-std=c++20", <--
    "-g",
    "${file}",
    "-o",
    "${fileDirname}/${fileBasenameNoExtension}"
]

I was debugging some of the stl strings (#include <string>). My solution worked only for <basic_string.h> that <string> includes, but not for <allocator.h> or <char_traits.h> that <string> includes too. I dont know why it is happening. Time to time, <basic_string.h> not working too for an unkown reason.

Im not sure this will work with user files (not standard library files)

[KorigamiK]

Im getting the same error

But when i added "-std=c++20" to my tasks.json

"args": [
    "-Wall",
--> "-std=c++20", <--
    "-g",
    "${file}",
    "-o",
    "${fileDirname}/${fileBasenameNoExtension}"
]

Im not sure this will work with user files (not standard library files)

Were you able to figure out any fix to this? I'm facing the exact same error!

[trogne]

@bim-ba , what do you mean ?

You get the error only when you add ""-std=c++20"" in the args ?

Are you using WSL ?

The file mapping does not work for glibc with WSL, so I did a symbolic link to fix that (read above).

[bim-ba]

Hello, @trogne and @KorigamiK, i added some extra information about my attempt to fix that. Thats it:

I was debugging some of the stl strings (#include ). My solution worked only for <basic_string.h> that includes, but not for <allocator.h> or <char_traits.h> that includes too. I dont know why it is happening. Time to time, <basic_string.h> not working too for an unkown reason.

I still dont know how to fix that......