Closed nunojsa closed 4 years ago
The outlining appears stuck waiting for tag parsing. There's a database (cylinder) icon at the bottom in your status bar -- what does it show when you hover over that? Is that icon getting stuck? Is CPU usage infinite? That could mean our parser is stuck in an infinite loop.
What triggers this? Opening particular files? Your logs don't show a lot of tag parsing going on.
Unfortunately I cannot answer to your questions. I cannot say what trigger this. It just happens. There is no obvious trigger that I could identify so far...
Is that icon getting stuck? Is CPU usage infinite? That could mean our parser is stuck in an infinite loop.
Next time this happens I will take a look an see if one the CPUs is stuck with the extension...
I will also see what happens when I hover over the cylinder...
Hopefully I can find something helpful.
I encountered a very similar issue. Also, I noticed the "tag parser initializing" icon on the vscode right bottom corner of the window is showing up, which is occurring to me too.
For my case, the C/C++ extension output tab indicates Failed to read response from server: 22
@legendecas The IntelliSense process is crashing. Can you attach a debugger to the Microsoft.VScode.CPP.IntelliSense.Msvc process to get a crash call stack? If it crashes on file open you could try cutting the code, attaching, and then pasting the code back so that it doesn't crash too early.
@sean-mcmanus I noticed there is a lot of processes named Microsoft.VScode.CPP.IntelliSense.Msvc.darwin
and Microsoft.VSCode.CPP.Extension.darwin
while the extension doesn't work. Restarting VSCode these processes don't exit as expect. Then I tried to kill all of them and restarted VSCode the extension comes to alive again. So far I'm not able to reproduce the case anymore.
@legendecas Yeah, dangling processes can cause the "tag parser initializing" issue (causing the Outline view to not work) because the other processes have a lock on the database -- we need to investigate why that is occurring and/or some way to detect/kill the processes. I'm not aware of dangling processes causing crashes though.
I have this issue as well. It started recently after I started using Git and pulling from a repository. Would Git have any effect on intellisense?
@Bscout2011 If new files are pulled from Git, it can trigger more database work that could affect the Outline view. Are you able to get the Outline view to recover? Steps to try are to make sure no processes are dangling and possibly running "Reset IntelliSense Database" and Reload Window from the Command Palette.
So this happened for me again. It seems one of the extension processes is completing consuming one of my cpus...
So, as soon as I killed the sleeping process/thread, the outline came back again. I guess a way to trigger this is checking out to different branches. I have changed branches quite some times today and (coincidence?) I got to reproduce this... Not sure if the attached file can help but it is all the log I had on my console since I started code...
Hope this helps!
@nunojsa We're tracking that issue with https://github.com/microsoft/vscode-cpptools/issues/2806. It should be fixed in our next release. Sounds like the same issue @Bscout2011 was hitting too.
So, is this supposed to be fixed with the latest release? The outline still breaks pretty easily when checking out to different branches. I guess, the bigger the project the easier this comes up.
One thing that I notice when this happens is that "tagging parsing file:" becomes really slow.... We can also see from the image that cpptools is consuming 100% on one CPU. Moreover the outline seen on the image does not match the opened file. It matches the file that was opened when the git checkout was done...
@nunojsa What version are you using? The fix for CPU usage after switching branches is fixed in https://github.com/microsoft/vscode-cpptools/issues/2806 is fixed in 0.27.0-insiders.
@sean-mcmanus that is the version I'm running...
We made some fixes, but there might be additional issues or it could be "by design". After the branch change, we will try to reparse files that have been recently modified. Are you using a single or multi root workspace? If the Outline doesn't match, it means we haven't re-tag parsed the opened file yet...does that eventually occur or does it get skipped? Does doing a save or edit save fix it? I recall we tried to give the current file higher parsing priority in the queue.
@Colengms Do you know anything more about this?
We made some fixes, but there might be additional issues or it could be "by design"
The outline just stops working, so I hope it's not "by design" :smile:
And actually now it seems to be worst than before. Even restarting code seems not to fix it. The outline does come up on the first file but as soon as I switch files it breaks.
On my setup I'm using compile_commands.json and when switching branches and in a project as big as Linux, a lot of files are refreshed and for sure the compile_commands.json won't be 100% accurate in the new branch (some files missing/some new). Can this be related with the problem?
The only way to fix the outline for me is to recompile the kernel and regenerate the compile_commands.json. Then, restart code and it seems to work again. I'm aware that I do need to regenerate the JSON file if I want my code navigation and preprocessor stuff to be properly handled. But I guess the outline (we should be able to gel all the symbols present in the current file) should still work even if I do not regenerate the JSON file.
Hope this extra info helps!
Yeah, I see what's happening -- the didChange change tag parsing that is from switching branching is getting put in the front of the same queue as the open file parse request, so it could get stuck behind a lot of work. For files that aren't opened, they should get pushed to the back of the queue, so the open files take precedence. Does that sound like what you're seeing? Otherwise, I'll need more repro details.
Actually, it's a little more complicated. Our parse_file queuing needs some re-working -- it runs into problems if too many files are changed, i.e. it can accumulate a backlog and some case it won't re-queue higher priority work if the work already exists in the queue, so if you open a file that is number 7000 in the queue, it'll have to parse those 7k files beforehand.
Looks like we regressed this around 6 moths ago when we added code that would re-parse changed files. The workaround is to Reload Window after switching branches.
Wait...you said restarting VS Code didn't fix it? That is usually a sign that a dangling process has locked the database.
I figured out an easy way to fix the issue where fileChanged events would block out didOpen/didSave work for the Outline view to update.
I figured out an easy way to fix the issue where fileChanged events would block out didOpen/didSave work for the Outline view to update.
Happy to hear that :+1:
I figured out an easy way to fix the issue where fileChanged events would block out didOpen/didSave work for the Outline view to update.
So, yes. After reboot, the outline comes for the opened file (on the saved session) and it does not work for any other file (apparently). It might be a timing thing and Im not waiting enough time for the outline to come up (in that case it's a long time for an outline).
Either way, I will wait for the next release and hopefully this is fixed!
Our fix is available with https://github.com/microsoft/vscode-cpptools/releases/tag/0.27.0-insiders3 .
You may still hit issue https://github.com/microsoft/vscode-cpptools/issues/5128 though.
So, basically, What is happening is that the outline just stops working after some time of usage. This happens with some frequency and it is a bit annoying since it is a very important feature to have. Restarting Code fixes it...
To Reproduce I don't know how to reproduce it but it happens with some frequency...
Expected behavior Outlines to work either with ctrl+shift+o and the panel...
Screenshots
Additional context This is what I can see after opening a new file:
This a log after rebooting coude...
log_after_reboot.txt