-
Notifications
You must be signed in to change notification settings - Fork 1.6k
rapid "IntelliSense process crash detected" for multiple crash types like request completion, update intellisence, etc. #11753
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
Comments
I am unsuccessful having the debugger halt on crashes. I followed your instructions linked above to attach to the srv process. Then when I am using the editor and type Whatever is crashing, is somehow not being caught by the debugger when I attach to the srv process. |
rolled back to v1.17.5 and v1.16.3. Both, I still get rapid intellisense crashes attempting completion. The only change is the C++ output window has a less specific crash notice went foward to prerelease v1.19.1. I still get rapid intellisense crashes attempting completion.
|
@diablodale Are you able to get a crash call stack with symbols using 1.17.5? We've found and fixed one completion crash for 1.19.2, but I don't think it would be one that would occur repeatedly. |
Yes as in #11753 (comment) both v1.17.5 and v1.16.3 reproduce the rapid crashes. |
@diablodale Yes, but with 1.17.5 you should be able to get symbols for a call stack. Symbols aren't published for 1.18.5/1.19.1. |
Just now, I can reproduce easily a The only time I've seen this kind of behavior is when the compiled EXE was not compiled with the needed debugger hooks. Are you sure (like missing symbols) that v1.17.5 was compiled with needed debugger info (and uploaded the the vscode download location)? Meanwhile, I turned on "All Exceptions" to get...something...and this occurred. Unknown if this is directly related to a "crash" appearing in the output window.
|
By turning on "All Exceptions" I can get the debugger to halt. When I hover over this specific static member, the debugger halts and I get this...
|
@diablodale A crash in clear_operand is not something I've seen before. It's crashing trying to compile some particular code. I'll look into it, but if you had a sample repro code that would help. |
We both need context to more easily do both our next steps. At least you have a function name and a deep call stack. :-) I have nothing but a hover over a static member variable. I have no context in which to reverse engineer the bug and afterward create a block of code for you. My mind tends to do well in reversing the bug, but in this case...the backward-tree of possibilities is too large. What can you do to give me more context? I need to know what code it was trying to compile, in what class chain, in what template chain, etc. I'm back up to v1.18.5 and today I have a new intellisense error
|
@sean-mcmanus, do you have any way to give me context so I can give you context and/or code? |
@diablodale Sorry, I've been busy. Yeah, a sample repro code would be good. I haven't had a chance too investigate that call stack yet. |
Got it. Other projects seem fine, I don't get these rapid crashes. I need to have logs, or scenarios. While you investigate the call stack, tell me if there are logs that I can use/enable that will tell us exactly what it was trying to parse and where. With info like that, I am more capable of reverse out a code scenario. |
Hi @diablodale . Given the frequently of the repro in that particular project, it's likely that there is some specific, perhaps even unusual bit of code in a header included by many of the sources. You might consider picking one of the simpler files the issue readily repro's in, then start tearing out code. If the issue repro's with completion, or is otherwise related to edits, maybe keep a function or class it repro's in, and start tearing out anything unrelated. Sometimes the code associated with an IntelliSense crash can be isolated this way, fairly straight-forwardly. It might also work to start with a file that #include's other files. If that repro's the issue, start removing #include statements until the issue goes away, to narrow it down to a particular file. Then do the same with that file's #includes. |
Hi. Checking back if cpptools has any logging or other diagnostic output so that I can see which source code line or area is causing these ongoing rapid crashes. Then I hope to be able to create a repro case. |
@diablodale Unfortunately, we don't have any logging that can enable showing the particular line that is causing the crash. You'd have to use some sort of binary search or possibly with "/EP" to generate a preprocessed file first. |
Environment
Summary
The last 2-3 days, the intellisense features are severely degraded. I suspect my code (or that of libraries) from this week has exposed a bug in some part of Intellisense. As I add more code (often c++20 and Eigen), I feel like it is continuing to degrade. As of now (Saturday), completion usually does not work. Meaning, when I have a var or class and I type the
.
or::
then nothing appears. Last week...I got completion lists of types, members, etc.Now...nothing except for crashes and the cpptools window noticing the crash
Repro
myclass::
and wait for the completionI know you want a minimal repro. I am unable to dedicate the tremendous resources needed to explore my entire codebase for how it would cause Intellisense to crash. I get the value in having bunch of cpp files to see it yourself, just not gonna happen with my scenario.
Result
Nothing happens. No completion list appears.
Expected
A list of members in the class, a list of functions, etc.
Configuration and Logs
Other Extensions
I have 30 extensions active, 3 of which are the cpp tools pack. Another 4 or 5 are the msft remotes. and so on. I will not be disabling 27 extensions at this time. I do not remember add/removing any extensions this week. But extensions might have updated themselves in-place.
I did disable copilot hoping that was the cause. However, was not. With copilot disabled I reproduced the symptoms and crashes.
Additional context
The symbols downloaded, and I attached to cpptools-srv. Often, the attach quietly ends. I'm trying to repro the crash...and then...I'm unexpectedly not attached anymore. If I were to guess, something is not a "crash/assert" and is causing the cpp-srv to exit. Which naturally ends the attach. Looks like #6151 wasn't completely fixed. Also...your instructions at https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv link to that now closed/fixed bug...time to update the instructions ;-)
I had to repeatedly attach over and over and finally got a crash that caused the debugger to halt.
But there is nothing interesting in the call stack. I see no symbolic info...
One time I saw two cpptools-srv processes listed.
The debug console has more interesting info. ITs a lot. Often complaining
debug-console.txt
Here is another crash and the debugger halted. Again the call stack has only addresses, no symbols. Are you sure your current extensions's live code has matching symbols on the server?
and in the debug console shows a access violation in srv
Exception thrown at 0x00000001403D8203 in cpptools-srv.exe: 0xC0000005: Access violation writing location 0x000000000000000C
I enabled DEBUG logging for cpp. In the c++ output window, is much private information. Though I saw the same errors at the top of this bug like
IntelliSense process crash detected: handle_update_intellisense
as well as many timesResetting IntelliSense server:
Here is that log with the filepaths redacted, defines removed, etc.cpp-log.log
The text was updated successfully, but these errors were encountered: