Blue cylon #1407
Comments
|
The typescript that does this is available at https://github.com/Microsoft/vscode-cpptools/tree/release/Extension so you can debug it that way (if you don't want to use wireshark). The offline installer should not need to download dependencies, but we still try to download a cpptool.json file, but that file is not necessary and it should just fail silently. I've never seen the symptom you're describing. |
|
You might want to change "extensions.autoUpdate" to false. |
|
Sean M,
Yes, when loading the extension through the normal means it would fail while trying to download the dependencies which the output suggested using the one found at "https://github.com/Microsoft/vscode-cpptools/releases" which does work. It just seems that after some time the cpptools goes into this strange state. I haven't figured out what I am doing to trigger the affect. I will change the setting for autoUpdate and see if that helps. |
|
Okay, I'll try to install the offline installer and see if I see this. We haven't shipped an update since December 18th so it seem unlikely that it updated. The root bug could be with VS Code or some other extension. |
|
Mr. Sean, Thanks, how would I go about debugging the issue on my end. It now seems I can't get the extension to work even after deleting the extension folder and re-installing it. I have started removing some of the extension to see if I can get it working again. Also, the PROBLEM tabs is showing that is can't open some of the files, but they are all located in the project space. I am not sure if need to all each folder to the c_cpp_properties.json file as the include path already has "${workspaceRoot}" which I image will look at all folders in a recursive manner. Regards, |
|
You could go to https://github.com/Microsoft/vscode-cpptools/tree/release and click the Clone button, then open the Extension folder in VS Code and then use Launch Extension in the debugger panel, but you would execute an online install though. Getting it to debug the offline installer path would be trickier. includePath is not recursive, so you'd need to add whatever folders you would pass to your compiler. browse.path is recursive and if that's set you should get a code action on the #include for adding the recursive directory that is missing. |
sean-mcmanus
added
Language Service
more info needed
|
Mr. Sean, Okay, thanks. I am not using VSC to compile the code as I am only using it as an editor. The build process require Python scripts and some other magic to build on a Linux machine. I did add a bunch of the directories to the include path and currently no PROBLEMS are showing up, but the commands line Peek Definition/Declaration or Go to Definition/Declaration bring up the dreaded blue eye cylon. I am going to leave it and try at home where the network isn't blocked. Perhaps that might help and if not, I will uninstall everything then re-install everything. Does cpptools keep cached files somewhere that I might delete just in case something might be in those files?? Regards, |
|
You're not using VSC to compile what code? Your own code? Go to Definition uses the browse.path settings. Check the database symbol in the bottom right to see if it's processing symbols (we have a fix pending for the slowness with that). We have a database for the browse.path, which is stored by default at `\AppData\Roaming\Code\User\workspaceStorage", but using the Reset IntelliSense Database command is easier to do. You might also try closing the workspace and then doing an uninstall instead of manually deleting the extension folder (which shouldn't be necessary). |
Yes, work code. For the "Updating Intellisense" icon (which look to be the little flame icon on the bottom) is red so it is currently updating the Intellisense. perhaps this is my problem all along??? The intellisense is updating and currently the blue eyed cylon is being shown. I will let it process and complete then try the "peek and go to" commands. In the past, from what my memory serves, once those commands were enable those functions worked. I used to use UltraEdit for the editing, but it had problems with a projects I was working on in the past with the intellisense, but SlickEdit, Visual Studio Code, and Visual Studio handled them well. Also, I just love the Peek Definition/Peek Declaration that cpptools provides. They are awesome!!! |
|
The red flame is only supposed to take a few seconds as it parsed the current translation unit (the database icon can take longer). If it's stuck, that means a failure is occurring. You can look at what the Microsoft.VSCode.Extension.[Extension|IntelliSense.Msvc].exe process are doing. The C/C++ Output window may show some errors if you set the C_Cpp.loggingLevel to Information. |
|
Okay, the little icon that looks like three disks took a bit of time to process, but it did complete. The little flame icon never goes away even after almost two hours. I enabled the logging as you suggested. Took me a while to find the C/C++ Output Window, but this is the output (sorry, I needed to hide the filename and paths since they are work related): IntelliSense Engine = Default.
|
|
I don't see any intellisense failure messages in the log. Is the Microsoft.VSCode.Cpp.IntelliSense.Msvc.exe stuck? Does it work when you open a simple file? It seems like something in the currently opened translation unit (C++ file and headers) could be causing a problem. We have one known issue that could cause this: #1294 -- is that issue related to your scenario? Go to definition doesn't use the IntelliSense engine, so if Go to Definition doesn't work, it probably means our main input thread is stuck due to the IntelliSense processing. In that case, you should probably change the intelliSenseEngine to "Tag Parser" until we're able to fix the issue (we generally need a small/isolated repro to fix intellisense parser errors). |
|
According to the bug report, "ll those processes stay alive after exiting VS Code. I have to kill " which wasn't my case when I last shutdown VSC. All the processes terminated. I have the following in the settings.json file // C/C++ After doing this the parsing completes and I am able to use the Peek/Go to functions (at least currently as I haven't spent a good deal of time having VSC open). With the setting "C_Cpp.intelliSenseEngine": "Tag Parser", set, what features are lost now that it isn't set to "Default"? |
|
Question, given the PROBLEM view shows files that was unable to be found, would those issues prevent the IntelliSense to complete and thus cause the blue eyed cylon? |
|
I uninstalled Visual Studio Code, removed all extension manually, purged everything from %USERPROFILE%\AppData\Roaming\Code. Re-installed VSC with the cpptools and bookmarks extensions. I haven't seen the issue other than once. I had opened 10 more file tabs and the IntelliSense processing did seem to get stuck (meaning I saw the blue eyed cylon), but after restarting VSC I haven't seen it again. |
|
When using This is a QoS bug that we need to fix, but there is also an issue with the IntelliSense engine we would like to understand better. If you are able to send us a code file that causes this behavior (or an anonymized version to protect your company's IP) we might be able to get a fix out more quickly. |
|
Mr. bobbrow, I am not sure what the time frame will be if this issue shows up again, but I will try to recreate it. I may re-install the previous extensions that I had installed to see if that reduces the time. I will try to collect as much data so the action item can be reproduced more easily. |
|
Okay, the problem has started manifesting itself once I got to work. I used Sysinternals Process Monitor and filtered on Microsoft.VSCode.CPP.Extension.exe and Microsoft.VSCode.CPP.IntelliSense.Msvc.exe. There were two items that jump out at me.
There are other action where the result is not SUCCESS also. I am not sure why this now occurring at work and not at the hotel last night. I guess I could use TCPView to see what connections are being made or attempted??? I can send the capture proc monitor, but I need a way to send it directly and not attached to this thread. |
|
Maybe I can try cloning some project from Github and hopefully I will see the same issue with that project? I will give it a try and report back when I have the data. |
|
The BUFFER_OVERFLOW result is "normal". I don't see any PATH NOT FOUND. Do you mean NAME_NOT_FOUND? NAME NOT FOUND can occur normally when we search files that optionally may exist. |
|
Mr. Sean, yeah, there are probably more NAME_NOT_FOUND are present also and probably more than the PATH NOT FOUND. I image I was just looking at a certain area of the events that had more of the PATH NOT FOUND.
|
|
Ok, I got PATH_NOT_FOUND. I occurs when our parser code can't find an include path (when it looks in a fallback /USR/INCLUDE location), which is normal (although we may remove that hardcoded path later). Setting your includePath correctly might fix that. |
|
Am I running into this problem of the IntelliSense stalling since all the include paths are not included thus not referencing all the directories? It gets a bit complicated since there are a number of files housed on the Linux server and spread throughout different directories (SDK, build/configuration type, etc)? |
|
If your intelliSenseEngineFallback is "Enabled" it should fall back to the tag parser if it can't find an include path. Using the intelliSenseEngine is not recommended if you can't get the include paths setup (it'll show lots of errors). Not finding include paths shouldn't cause an IntelliSense stall normally. If your build systems uses Cmake you can generate a compile_commands.json to automatically generate the settings required. If your browse.path includes the root of all the headers, then you can use the include path code actions to add the includePath settings, but it's possible you may need to edit the ordering still. |
|
Even if VSC/IntelliSense doesn't have all the include paths it should be able to navigation though the project tree to determine which files are present and parse those. If certain files are not available which result in some reduce visibility of auto-complete, quick info, parameter hints I am fine with that. Generally, I don't care if some of these insights are not available for files like stdio.h, string.h or intrinsics. So long as the IntelliSense is able to parse all the file in the project tree (regardless of me setting up the include paths, which by the way are generally underneath the main project folder) I am a happy camper. |
|
Oh, so it sounds like you have the intelliSenseEngineFallback Disabled and I assume Disabled errorSquiggles. IntelliSense can parse the file without the headers, but any usage of code defined in those headers will generate an error. If there's some stalling in this scenario, I think we need a repro, unless @bobbrow has any ideas for further diagnosis. |
|
Mr. Sean, I haven't change the default setting of C_Cpp.intelliSenseEngineFallback, which shows "Enabled" in the default settings. This should had been the case even during the encounter of the blue eyed cylon. I still need to clone "something" on github and see if I can reproduce the problem. I did talk with a co-worker who also uses VSC with cpptools and he stated he is seeing the same issues I have. At least it is consistent between a couple of machines. Is it possible to clone the extension, debug the extension while using this project? I know in a previous comment it was stated I can clone the cpptools, but I wasn't clear if I can debug extension using my current project???? |
|
Our typescript is debuggable/open sourced, but our parsing code that runs in the executables is not, so I don't think debugging the typescript would help. |
|
When you open a new C++ file (preferably a large translation unit) -- what is the behavior of the Microsoft.VSCode.Cpp.IntelliSense.Msvc.exe process? Does it seem to do any parsing? If you could send us a 32-bt dmp (or call stack of interesting threads, if you can get symbols) of the Microsoft.VSCode.Cpp.IntelliSense.Msvc.exe process that is stalled, that might help us fix the issue. |
|
Definition question, what is a "large translation unit"? Where might I get one if needed? |
|
A large C++ file or a C++ that has a big #include graph (lots of include files). |
|
@bobbrow / @sean-mcmanus , how can I send a process dump to you guys? I don't want to post it here. Perhaps I can placed it in a shared drive then send the link to you guys via email or other means? |
|
Yeah, you can send us a shared drive link via email. You can use c_cpp_support@microsoft.com or email directly. If you open the dmp, the call stack symbols are supposed to be resolved via the public Microsoft symbol server, so you could send us just the call stack text too (if the symbols don't resolve we should try to fix that). |
|
@sean-mcmanus okay, I wanted to send a few dump files from the project I am using as I thought it might be okay given I see the behavior with these files. I had sent an email to you (at seanmcm@microsoft.com), but I didn't get a response (not that I waited for one that long). |
|
Oh, yeah, I get a lot of email so I missed your email by accident -- I see it now. |
|
Oh!! How do I create a 32-bit dump file not using the Task Manager then? Not used to developing Windows applications so a bit ignorant on the subject matter. Edit: I think I found it: C:\Windows\SysWOW64 folder and the name of the file is taskmgr.exe |
|
Close any currently running task managers, then run |
|
@sean-mcmanus, I saw something odd with the C_Cpp.intelliSenseEngine set to "Tag Parser". I had tried a Peek Definition command and saw the blue eye cylon with the following in the OUTPUT window. After a minute of capturing the data I had retired the operation and it seemed to work. This scenario has happend a few times today (never seen it before this time, though VSC just updated to 1.19.2 [Error - 2:21:12 PM] Request textDocument/documentHighlight failed. |
|
I think the handleConnectionClosed error means our language server process has crashed. Another user reported this #1373 . We have a known crash with documentHighlight that started reproing with 0.13.0 when we added the feature, but we don't yet know a repro...might still be fixable. If you can enable local dumps on Windows and either send the dmp or report the call stack that would help identify which crash this is exactly. |
|
Okay, I will try to reproduce this later today. Edit: Added the following for local dumps, let me know if I need to add more. Both are configured for full dumps. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\Code.exe HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\Microsoft.VSCode.CPP.Extension.exe |
|
The dmps you sent have no crashes in them. They appear to have threads blocked waiting for work. You don't need Code.exe dmps. Microsoft.VSCode.CPP.IntelliSense.Msvc.exe is for IntelliSense process crashes. |
|
@sean-mcmanus I didn't add Microsoft.VSCode.CPP.IntelliSense.Msvc.exe since I didn't think the Tag Parser was using it. I will add it. I may not need the Code.exe dumps, but I added it as a just in case.
|
|
The dmp you sent is the IntelliSense engine blocked waiting for source from the main process. We believe the main process is stuck (possibly due to waiting on the intellisense thread) and unable to send the response back leading to a deadlock. Could you send the matching DMP for the Microsoft.VSCode.CPP.Extension.exe ? I'll try to review the code to see if I can prevent this from ever happening. The documentHighlight issue could be the process crashing (fix pending). I forgot that the local dmps don't work for our extension because VS Code does something tricky to block it, so if you see a process disappear in the task manager when it shouldn't, that means a crash is occurring and you'd need to attach a debugger beforehand to get a dmp/call stack. |
|
The main process is in a normal state and not blocked. It appears somehow the get source request is somehow lost (shouldn’t be possible), but we don’t have enough information to diagnose why, we probably would need to add more debugging info to the code. |
|
Mr. Sean,
Well, that is unfortunate. I am more than willing run some
debug/internal version of VSC if you need me to help figure out the
problems. Just let me know.
Out of curiosity, what program/utility do you use to decode the dump
files?
Regards,
Mark
…On Fri, Jan 12, 2018 at 4:25 PM, Sean McManus ***@***.***> wrote:
The main process is in a normal state and not blocked. It appears somehow
the get source request is somehow lost (shouldn’t be possible), but we
don’t have enough information to diagnose why, we probably would need to
add more debugging info to the code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1407 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA7Ncog44bpj8sHy0KJYAz2vkfj3oZtOks5tJ_fhgaJpZM4RT1st>
.
|
|
I used VS Community 2015, but that's just because it was configured for DMP files a long time ago. VS 2017 is preferred. WinDbg might also work. Public symbols might be available, not sure. |
|
We have never seen this bug symptom or seen other user reports of it so it's strange (the normal errors we see are just crashes, infinite loops, and thread deadlocks). If you can repro the bug via restarting VS Code and having only 1 C++ file open and opening no other files, then sending those 2 dmps might help. Also, if you can find the smallest translation unit that repros the bug (i.e. the smallest memory usage by Microsoft.VSCode.CPP.IntelliSense.Msvc.exe) that might also help, preferably with the smallest number of #includes, preferably none. If the bug requires > 1 file open or requires the file have #includes that might also shed light on the cause. Reducing the |
|
@sean-mcmanus, okay, let me see if I can collect some meaningful data for you. I think I had mentioned that my other co-workers do see this issue also, so obviously it is project related and not just machine/individual related. |
sean-mcmanus
added
fixed
|
This deadlock issue should be fixed now with 0.17.1. |
|
Mr. @sean-mcmanus, oh, you guys found the source of the issue?? That is fantastic. I didn't realize you guys were still looking at this. Thanks so much for fixing this. |
|
Yeah, multiple other users continued to hit this (same dmp and call stack involving "contains_source"), and by accident, another change we made caused this to suddenly start reproing very easily, which enabled us to find/fix the root cause (threads hidden/stuck in our thread pool were causing an interprocess deadlock, particularly for machines with fewer logical processors). |
Hello,
One of the primary issues I have with cpptools is that it goes into some mode to where a blue rectangle is moving from left to right just beneath the file tabs. Generally I believe it is showing status when installing/updating an extension. Once this occurs I need to manually delete the extension from %USERPROFILE%.vscode\extensions\ms-vscode.cpptools-0.xx.x then reinstall it.
My company appears to block a lot of content so in order install the extension I must download the offline (?) extension from https://github.com/Microsoft/vscode-cpptools/releases.
OS: Windows 10 Enterprise
VSC: 1.19.1
Other Extensions: Bookmarks, Bracket Pair Colorizer, C# for VSC, Code Runner, Code Spell Checker, Git Blame, Git History, Path Intellisense, PowerShell, and Project Manager.
I wonder if cpptools is trying to determine if a a new version if out there. I didn't find any setting to disable automatic updates or anything related to self updating.
I guess a next step would be attaching wireshark and seeing if its actually trying to communicate with the outside work.
Mark
The text was updated successfully, but these errors were encountered: