Configuration Provider messages may be delivered prior to initialization completing. #11192
Assignees
Labels
bug
Language Service
more info needed
The issue report is not actionable in its current state
reliability
Comments
|
Hi @gracicot . If no source files are open on startup, does the crash still occur immediately? If not, could you try attaching the debugger to the
Would it be possible to provide the project that triggers the crash, or reduce it to something simpler that you can share? |
Colengms
added
Language Service
more info needed
|
I can confirm that if no source file is open on startup, the crash doesn't occur. I'm not able to attach gdb to the process since launching the cpptools debugger crashes the extension before the debugging starts. I was able to do it using gdb from the terminal. Here's the backtrace: The disassembly layout give me this output in the tui: It seems it has a hard time getting the workspace folder, but my path don't look weird to me: Let me know if you want more information. |
|
Hi @gracicot . Am I correct that this stack was for the scenario of activating the extension by issuing the Log Diagnostics command? (I see My suspicion is that you're seeing an issue due to initialization either having failed, or a problem with internal messages being delivered before initialization is complete. (The crash appears to be related to assuming there is at least one workspace folder object, internally, and there is always one such entry delivered during initialization, but none were present). Could you enable the setting |
Yes.
I enabled that settings and I'm getting the same output: Here's the backtrace when opening a file: Here's the disassebly of around where the executable segfaulted: |
|
Hi @gracicot .
I don't believe that particular output it coming from the "C/C++" Output channel. That looks like something VS Code itself is outputting. Could you provide the output from:
I don't believe we'll need any more stacks or disassembly. But, the C/C++ log (before any "sending request failed" errors occur) might provide clues as to how it got into that state. |
|
Ah! I didn't realized there was a second place where logs could appear. Especially since that Here's the debugging output: |
|
I find it weird that files from the build directory appear in there, and non c++ files also appear. |
|
Hi @gracicot . Is this with a workspace with 10 separate roots? It looks like CMake Tools sent 10 (or more?) identical configurations, which seems unusual. I believe these arrived before initialization was complete, as certain expected log messages from initialization were not present. If you disable CMake Tools temporarily (long enough to allow the C/C++ Extension to initialize), does that address the issue? I'll use this GitHub issue to track investigating and address custom configuration messages can getting through prior to initialization completing. |
Colengms
changed the title
Colengms
removed
the
more info needed
|
No I just did a simple |
|
I don't see any output anymore for C/C++, I only see cpptools: |
|
Is there any other way I can obtain the logs? |
|
Hi @gracicot . Do you still have Perhaps we saw a flood of messages from CMake Tools due to returning an error in response to them (since we weren't initialized yet), and it simply kept retrying.
Would you be able to isolate what is special about this particular folder that triggers the issue? It would seem that the initialization message is failing, so perhaps there is something unusual about the contents of |
Colengms
added
the
more info needed
|
Hey sorry for the silence, I'm a bit more free now. I confirm there is no There is other logs I can give you though. This is the developer tools output, all extension disabled except cpptools, .net install tools and editorconfig: The output goes all the way to the line with the content I hope it helps! |
|
In addition, here's my
|
|
Oh, removing that file association fixed the issue. I never remember writing that, I always assumed that was auto generated. As far as I can remember, I always used the UI to edit my configs. |
|
Closing this as a dupe, in favor of: #11375 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Environment
Bug Summary and Steps to Reproduce
Bug Summary:
Crashes on startup with output:
Steps to reproduce:
Expected behavior:
Intellisense should start normally
Configuration and Logs
Other Extensions
vscodevim.vim
Additional context
I also tried to change intelliSenseMode from clang to gcc but no changes in behaviour.
Interestingly, only one of my project seems to crash.
Running command
C/C++: Log Diagnosticscrashes the extension too.The text was updated successfully, but these errors were encountered: