-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Format on save with clang-format takes too long #6809
Comments
When this occurs can you check which process is using CPU? If it's cpptools, then the formatting might be blocked on another operation (or possibly processing the formatting result), in which case, if you set C_Cpp.loggingLevel to "Debug" and check the formatting-related logging that can help determine where it's getting stuck (or attaching a debugger and getting a call stack: https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv). If it's clang-format, then it would be a clang-format bug. |
Hi @xolom . When this happens, can you check whether or not clang-format is still executing (based on the Activity Monitor) ? Also, I noticed that you repro'ed this with 1.1.3. Could you try upgrading to 1.2.0-insiders2 ? We recently upgraded the bundled version of clang-format to 11.x. |
Hi. I was already @ 1.2.0-insiders2, when i made the post above. I just checked if
On the other hand there are many running
|
What i also noticed is following message in the log: Today i mostly worked mostly only in one I already tried to speedup the parsing as much as possible by only include the necessary folders, setting |
Hi @xolom . Is the code involved rather complex? With debug logging enabled with I suspect the cause of the issue is an operation prior to formatting that is trying to synchronize with the results of an IntelliSense pass. We have a known issue in which certain combinations of operations might result in a delay for this reason. We have some ongoing work that should lead to addressing the issue. Can you identify the combination of operations prior to formatting that lead to the delay? It's likely due to making an edit, hovering, then closing the file before the hover operation is complete). Depending on your specific repro, there may be something we can do to address it sooner. |
Hi @Colengms. From what I have seen in the log these are the values coming up over the day:
I'll try to find out, if there is any specific action happening before i save the file and |
I'm pretty sure that Unfortunately i can't attach |
I'm experiencing the same issue on Windows and the issue disappears when downgrading the plugin to i think 0.29, but then again much of the functionality gets lost too. |
I'll try once I'm able to reproduce the issue again. I've kept the format on save feature disabled for a few days due to this bug and now after re-enabling it im having trouble recreating it. |
Call Stack for the main thread of cpptools. ntdll.dll!_NtReadFile@36�() (Unknown Source:0) |
the cpptools-srv are all here: ntdll.dll!_NtWaitForSingleObject@12�() (Unknown Source:0) |
@Dakror can you share the stacks from all threads? |
From what i could see, all other threads appeared as worker threads all waiting on some lock. |
I would expect there to be one thread waiting for clang-format. It would be in the cpptools process, not cpptools-srv. |
one thread looks like this:
another one like this:
the others are all the same with:
|
I don't see any call stack that shows any work being stuck. The only one with work shows it's parsing defines from querying the compiler -- if you let the program run, does it show a different call stack for that thread? |
stepping up seemed to fail at the level of the regex iterator operator++. the program seems to be stuck there and repeat everything below it infinitely |
Oh, that is odd -- the regex is just being used to split the input into multiple lines. Not sure yet what could cause that to fail... |
Actually correction, the frame above it is the one running forever, the msvc::split_string |
Yeah, split_string uses the regex iterator in a loop. What compiler and version are you using? What do you get when you use |
|
I now finnally could manage to get lldb running with running Call stacks of cpptools:
Call stacks of cpptools-srv:
I noticed now that this behavior only occurs when i open a relatively big file (86k LOC) which is in another workspace, where |
Finally :D |
The issue doens't repro if the "-Xclang" arguments are removed, i.e. the bug is that the filtering out of the ipch file argument doesn't work with the "-Xclang" arguments. |
Depending on which single -Xclang you remove from the 6 that are in my command for instance, you get a different output... |
Yeah, we weren't handing -Xclang correctly in all cases and we weren't handling -include-pch correctly as well. The fixes should be in 1.2.1 unless we decide to delay it for some reason (eta Wednesday or Thursday). |
I moved it to #6944 since it doesn't like it's the same as the original issue. |
I've noticed that IntelliSense consistently puts error squiggles under all my library includes after build completion, is this related? since I use PCH for everything really |
I now could catch a call stack again. That looks more promising than the last one.. cpptools:
cpptools-srv:
Intellisense completely stopped working. |
@Dakror Actually, it looks like I was mistaken -- IntelliSense should still work when -include-pch is used (at least after our fixes to handling that argument)...our non-handling of pch files is just an optimization we're not doing, but the headers should be found via the normal mechanism still (they just have to be reparsed from the .h files like normal instead of re-used from the precompile files). If you still see error squiggles after 1.2.1 (assuming the fix makes it into that release), you could file a new issue so we could investigate (using the C/C++: Log Diagnostics and checking the C/C++ logging with "Debug" C_Cpp.loggingLevel could help identify the issue). UPDATE: Specifically, the .hxx header should get picked up by the "-include" (forcedInclude) argument (after the -Xclang issue is fixed). Otherwise, paths might need to be added to includePath. @xolom Those call stacks still show no work being done. Those threads are normally in that state when they don't have any work to process. |
@Colengms As the call stacks aren't showing any work being done, could it be some communication issue? |
@xolom Yeah, 1.2.0 switched to a new interprocess communications system between cpptools and cpptools-srv, so something could be causing a communications failure. We're aware of 1 crash that could occur in either process -- not sure if that crash could lead to the symptoms you're seeing though (should be fixed with our pending 1.2.2-insiders, not 1.2.1). Some users at #6958 on Mac may be hitting the same issue. @Dakror Your issue is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.1 . |
Yes, thank you so much! |
@sean-mcmanus That other issue sounds very familiar and i think there is a connection.. I will keep trying to get a useful call stack. |
@xolom The issue we believe we have fixed for 1.2.2-insiders would be a 1.2.0 regression. I'm not sure if there would be an interesting call stack if that bug were hit. My previous comment mentioned a "crash", but it looks like it wouldn't be a crash, but some other interprocess communication failure, i.e. it seems like it could be the same issue you're hitting. I would wait till we release 1.2.2-insiders soon to see if that fixes it. |
@xolom Can you check if https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.2-insiders fixes this issue for you? |
@xolom We believe this is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.2 . Let us know if you're still hitting issues. |
So far i had no issues. Looks like it is fixed! |
Describe the bug
Sometimes format on save with clang-format takes really long. I need to cancel the task to save the file. What is the cause for that, how can i debug that further? I see this popup for like forever
The text was updated successfully, but these errors were encountered: