Parsing Open Files Stuck in Infinite Loop about vscode-cpptools HOT 12 CLOSED

Hi @calderkatyal . Thank you for providing your configuration and detailed logs. It sounds like you're seeing "Parsing Workspace" never complete?

Since your logs are partial, can you repro again and check if Done parsing remaining files. is ever output? If not, can you identify the very last file that it was attempting to parse? It should be indicated using tag parsing file:. It sounds like our tag parser may be having an issue with that file. Perhaps we can isolate something about that file that might help us address the issue. Though, if you do eventually see more and more tag parsing file: log statements, it may be making slow progress and may be a matter of time before it's completed parsing all project and compiler sources and headers.

from vscode-cpptools.

@calderkatyal Is it fixed if you use

            "includePath": [
                "${workspaceFolder}"
            ],

instead?

from vscode-cpptools.

@Colengms @sean-mcmanus I believe I have found a solution: I changed the line "includePath": ["${workspaceFolder}/**"], to "includePath": [ "${workspaceFolder}/*"], (removed a star) which seems to have resolved it. Keeping this thread open for a day while I test if the issue is gone and if so I will close the issue.

from vscode-cpptools.

@calderkatyal ${workspaceFolder}/** is recursive includes and recursive browse path, ${workspaceFolder} is non-recursive includes and recursive browse path (might fix it if "Resolving recursive includes..." is getting stuck), and ${workspaceFolder}/* is non-recursive includes and non-recursive browse path (generally not wanted since symbols in sub directories won't be parsed, but if that is required to get it to not be stuck, then that would suggest there is some problem with directory iteration through your workspace folder, possibly a really large folder or a symlink to the root).

from vscode-cpptools.

@sean-mcmanus Ah okay. Then the single * is undesirable. The root directory is small (can get exact size if necessary) and I'm not aware of any symbolic links to big directories. From what I can tell the clog seems to be occurring from the recursive calls to parse #include derivatives (mostly just standard header files). However the extreme parsing time is unexpected. Is there a way to optimize this?

from vscode-cpptools.

@sean-mcmanus To clarify, ${workspaceFolder} was also not working when I tested it. Still the same infinite parsing error on #include derivatives...

from vscode-cpptools.

Hi @calderkatyal . Can you provide the information request?

Since your logs are partial, can you repro again and check if Done parsing remaining files. is ever output? If not, can you identify the very last file that it was attempting to parse? It should be indicated using tag parsing file:. It sounds like our tag parser may be having an issue with that file. Perhaps we can isolate something about that file that might help us address the issue. Though, if you do eventually see more and more tag parsing file: log statements, it may be making slow progress and may be a matter of time before it's completed parsing all project and compiler sources and headers.

There are a number of possible issues this could be. That information would help us identify what's happening. For example, the issue could be that a certain file is causing a deadlock or extreme slowness in the parser, that files that shouldn't be parsed are being parsed, if parsing speed is impacted by something on your system, or if it's simply taking longer than you'd expect.

Note that if you want to exclude any directories from tag parsing, you can directly control the set of paths that are parsed using a browse+path field in c_cpp_properties.json or the C_Cpp.default.browse.path setting.

from vscode-cpptools.

@Colengms I believe the tag parsing of LinkedList.h has finished -- that is the open file and it's moved on to trying to get the recursive includes. It appears to be some problem with the directory iteration getting stuck. Their logging doesn't indicate it has started tag parsing the workspace -- it hasn't finished the search_root phase.

@calderkatyal Is CPU being used? Your reference to "infinite loop" suggests cpptools is using CPU still and not deadlocked. Are you able to set C_Cpp.loggingLevel to the hidden value of "7" and see what the directory iteration logging shows it is doing? Or attach a debugger to the cpptools process to get a call stack of the thread that is doing the directory iteration (the search_root call should be on the stack). And as Colen mentioned, you can use the browse.path to limit the directory iteration (as well as potentially C_Cpp.files.exclude).

from vscode-cpptools.

@sean-mcmanus Setting C_cpp.loggingLevel to "7" is not permitted Value is not accepted. Valid values: "None", "Error", "Warning", "Information", "Debug". Code is indeed using considerable CPU while parsing.

@Colengms @sean-mcmanus From now on to isolate the environment I am testing with workspace as a simple old directory hw0 which contain only two simple HelloWorld files written in C and corresponding executables (eg. this is the root directory open on VsCode). The only #include directive is to <stdio.h>.

I have waited for 15 minutes open solely opening the directory (no interactions with files at all) and see the following log (see attached).
log.txt

While no further logging statements are made, the IntelliSense wheel is still spinning and I see IntelliSense: Updating and Parsing Open Files, both in seemingly infinite loops. It seems that the last log that is always made is Done populating filename cache. Elapsed time: 14 ms, although even to get to this log considerable time is elapsed. Here is the log at this time
log.txt

EDIT: Now after waiting for 20 minutes parsing is finally complete. I am using the recursive setting ${workspaceFolder}/** but operating in a very small directory with only one #include directive.

Reattempting parsing in the original directory of my initial query

Upon opening VSCode at the original larger directory referenced in my initial query, I am observing the same slow behavior and have currently been waiting for parsing to finish. In particular, I have been stuck for a very long time on Resolving recursive includes... which does not provide further debugging statements after. I am happy to use browse.path to limit paths that are parsed but am wondering more largely if this is expected behavior for medium-sized directories (albeit with considerable #include directives. I also don't know which paths to limit as debugging is not outputting very useful statements. I don't really know how to "attach a debugger to the cpptools process to get a call stack of the thread that is doing the directory iteration," but am happy to try to figure it out if you think this would be a helpful way to go.

Note: as I am finishing this message I am still currently parsing. I see a bunch of debug statements in the form of. LSP: (invoked) cpptools/fileDeleted: file:///home/accts/ckk25/.vscode-server/data/User/workspaceStorage/3c578823a4e4270c9be16d8156efa182-3/vscode.lock or similar which I cannot pretend to understand.

Thank you for your assistance.

from vscode-cpptools.

@calderkatyal You can ignore the c_cpp_properties.json warning -- the hidden value of "7" should still work, but you only need that if you want to investigate which directories are being traversed so you can potentially exclude those.

You should add "**/.vscode-server": true to your "C_Cpp.files.exclude" setting, plus any other folder exclusions that shouldn't be parsed for global symbols (that you might see in the logging) -- the alternative would be to opt-in the subfolders of the ${workspaceFolder} you want, via setting your C_Cpp.default.browse.path setting or the equivalent in c_cpp_properties.json. Normally, you wouldn't do Open Folder on a folder that contained .vscode-server and other application folders (you may want to open the smallest folders that contain your C/C++ code, potentially multiple folders added to a workspace file).

There's a info on how to attach the debugger to cpptools at https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv, but it might not be necessary if the logging is sufficient, and you'd probably need 1.20.2 to get a call stack on Linux due to a fix in that release.

from vscode-cpptools.

Hi @calderkatyal . These configuration details and log messages suggests you are opening your (OS) user directory a workspace folder. Is that correct?

            "includePath": [
                "${workspaceFolder}/**"
            ],

    "includePath": [
        "/home/accts/ckk25/**"
    ],

LSP: (invoked) cpptools/fileDeleted: file:///home/accts/ckk25/.vscode-server/data/User/workspaceStorage/3c578823a4e4270c9be16d8156efa182-3/vscode.lock

The C/C++ Extension (and VS Code itself to a large extent) is designed with the assumption that the "workspace folder" open in the editor is a 'project folder', and not a root file system or user directory. All contents of that folder are indexed, and any potentially appropriate files parsed. The C/C++ extension (and other extensions) will recursively scan that directory structure looking for files to parse or which might trigger their activation. VS Code itself will spend significant resources monitoring and processing notifications for all files in that directory structure, informing extensions of their state. This is a likely cause of performance issues.

from vscode-cpptools.

@Colengms The issue was that the parsing problem persisted despite using small workspace folders, but it seems to have resolved itself after I allowed it some time to parse and also deleted a couple stray large project files. We can close this thread as I think it is clear that the issue was related to poor file management which can be solved by either deleting large extraneous files or removing them from the parsing path.

Thank you @sean-mcmanus @Colengms for your help and apologies for the extent to which this was caused by my own ignorance.

from vscode-cpptools.