clang-format based formatting breaks after a while since last VSCode update

[MikeWeller]

Type: LanguageService

Since the VSCode update a day or two ago, clang-format based formatting of C++ code stops working after a few times invoking the "Reformat Selection" or "Reformat Document" commands. Once it gets into this state, even introducing a deliberate error in my .clang-format and trying to format doesn't print out an error in the Output window, which it usually does before it gets into this state. Closing and re-opening the window fixes the issue for a while before it happens again.

Describe the bug

• OS and Version: Windows 10
• VS Code Version: 1.31.0
• C/C++ Extension Version: 0.21.0
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

To Reproduce

Unfortunately I haven't yet figured out precise reproduction steps. It just seems to stop working at random. I shall continue to try debugging this.

1. Use the "Format Selection" and/or "Format Document" actions multiple times. Eventually it stops doing anything.

Expected behavior

The "Format Selection" and "Format Document" actions should continue to work.

Screenshots
N/A

Additional context

I turned on "C_Cpp.loggingLevel": "Debug" but triggering the format section/document actions don't produce any output in either the success or failure cases.

I did however notice that if I restart the window, once I see this shortly afterwards, the format command is broken:

Checking for syntax errors: file:///c%3A/redacted/redacted.cpp
queue_update_intellisense for files in tu of: C:\redacted\redacted.CPP
errorSquiggles count: 0

Sometimes though, I don't see the above messages and formatting works (I instead see these messages):

Populate include completion cache.
Discovering files...

I don't know if this is relevant or not.

[MikeWeller]

Note there is a previous similar report here but since it is a few years old and was closed with no apparent resolution: #1090

[MikeWeller]

Also worth mentioning it breaks for all tabs once this happens.

[MikeWeller]

After playing some more, I don't think those particular log messages I saw were relevant.

[sean-mcmanus]

It sounds like the main input thread of the extension is stuck? The formatting work is done on the main input thread, so if some other main thread work could block the formatting. When formatting doesn't work, do any other features like hover or go to definition work?

Is this a multi-root folder?

It sounds like you're saying this is a regression? If you downgrade our extension to 0.20.1 does the bug still repro?

[gcwenger]

@sean-mcmanus I was also experiencing this bug with clang-format not working with C/C++ Extension Version: 0.21.0.
Downgrading to 0.20.1 seems have fixed the ability to use clang-format for me.
For me the other questions you asked re formatting don't apply because I have formatting disabled (in favor of cquery use):

"C_Cpp.autocomplete": "Disabled",
"C_Cpp.formatting": "Disabled",
"C_Cpp.errorSquiggles": "Disabled",
"C_Cpp.intelliSenseEngine": "Disabled",

[MikeWeller]

Downgrading the C++ extension to the previous version (0.21.0) did not help. Downgrading VSCode to 1.30.2 does fix the issue. I haven't tried going to 0.20.1 of the extension.

[gcwenger]

@MikeWeller Agreed. Although downgrading the C/C++ Extension initially seemed to help, I later had clang-format become unresponsive again.
I've since downgraded to 1.30.2 (and selected "none" for the Update Channel to avoid it upgrading right back to 1.31). In 1.30.2 invoking clang-format via "Format Document" seems to be reliable again.

[sean-mcmanus]

Yikes, it sounds like you guys are describing a regression with VS Code 1.31.0 and not our extension? I don't seem to be able to repro the issue.

Our 0.22.0 release should fix the formatting getting blocked by IntelliSense operations (in most cases).

[Srekel]

Also seeing the same issue. I looked in the Problems tab but not seeing anything related to this. I also set loglevel to debug but I'm not sure where to look.

Actually, one thing that sticks out in the Problems tab:

It compiles fine (in VS, and Clang on Linux) so it isn't an actual error. But it is a rather convoluted macro, so maybe the VS Code parser can't handle it...?

@sean-mcmanus May I ask when 0.22 is due?

[sean-mcmanus]

@Srekel 0.22.0 is planned for Thursday this week (unless issues delay it to next week), but I'm not sure yet if the fix for formatting getting blocked by IntelliSense processing will get checked in or not.

The "expected a ')'" looks like a different intellisense bug and should be unrelated to clang-format issues. Can you provide more repro info, such as the definition of WC_VFUNC?

[Srekel]

Ok! Looking forward to it. :)

The call site with the error:

WC_INLINE void
print_fmod_error( const char* msg, FMOD_RESULT result ) {
    const char* err = FMOD_ErrorString( result );
  WC_LOG( "FMOD error! (%i) %s. Message: %s\n", result, err, msg );
  ASSERT( false, "FMOD error! (%i) %s. Message: %s\n", result, err, msg );
}

Here's the full error popup:

expected a ')'
#define WC_LOG(...) WC_VFUNC(WC_LOG,__VA_ARGS__)
Expands to: sys_printf( "%#T|" "%-12s|%4u:%-30s " "FMOD error! (%i) %s. Message: %s\n", result, err, msg "\n", "WC_UPPERCASE_PROJ", sys_u32( 26 ), (sys_strrpbrk("C:\CYGWIN64\HOME\SREKEL\GIT\WARPCORE\AUDIO\FMOD_UTIL.H", "\/") + 1), , , )

This is the actual code:

#define WC_LOG(...) WC_VFUNC(WC_LOG,__VA_ARGS__)

#define WC_MERGE_ACTUAL(name, n) name##n
#define WC_MERGE(name, n) WC_MERGE_ACTUAL(name, n)
#define WC_VFUNC(func, ...) WC_MERGE(func, WC_NARG(__VA_ARGS__)) (__VA_ARGS__)

// Macros to make macro 'overloading' available
#define WC_EXPAND(x) x
#define WC_NARG(...)  WC_NARG_ACTUAL(__VA_ARGS__,WC_RSEQ_N)
#define WC_NARG_ACTUAL(...) WC_EXPAND( WC_ARG_N(__VA_ARGS__) )
#define WC_ARG_N( \
_1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63,N,...) N

#define WC_RSEQ_N \
63,62,61,60,                   \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9,8,7,6,5,4,3,2,1,0


#define WC_LOG1(STR) sys_printf( "%#T|" "%-12s|%4u:%-30s " STR "\n", WC_TOSTRING( WC_UPPERCASE_PROJ ), sys_u32( __LINE__ ), WC_TO_FILENAME(__FILE__) )
#define WC_LOG2(STR,a0) sys_printf( "%#T|" "%-12s|%4u:%-30s " STR "\n", WC_TOSTRING( WC_UPPERCASE_PROJ ), sys_u32( __LINE__ ), WC_TO_FILENAME(__FILE__), a0 )

[davydden]

@sean-mcmanus I also have the same issue with clang-format not working after a while. vscode restart helps. This is on

VSCode 1.33.0
C/C++ 0.22.1
OS: macOS Mojave 10.14.4

[sean-mcmanus]

@davydden If you're using multiple workspaces roots, we have a known issue where the didOpen won't be sent to all the folders, which can cause formatting to break.

[davydden]

@sean-mcmanus

If you're using multiple workspaces roots, we have a known issue where the didOpen won't be sent to all the folders, which can cause formatting to break.

you mean when a workspace has multiple folders with C++ code? If so, yes, that's exactly my case. Could you perhaps point to the issue to track?

[sean-mcmanus]

@davydden Issues (I think they're dups of each other): #2107, #1073 .

[MikeWeller]

Any updates on this? I'm stuck on an old vscode and plugin because this is quite important to my workflow.

[Jacky-Lau]

I also have the same issue and restart won't work.
Here's my log:

Error: Failed opening file /Users/jackylau/Library/Application Support/Code/logs/20190505T182625/exthost1/output_logging_20190505T182628/6-C/C++: mmpayo2o.log for writing: Operation timed out
	at Object.createRotatingLogger (/Applications/Visual Studio Code.app/Contents/Resources/app/node_modules.asar/spdlog/index.js:34:9)
	at Object.t.createRotatingLogger (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:290:530)
	at new r (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:629:222)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:631:639
	at Generator.next (<anonymous>)
	at s (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:11:9)

[sean-mcmanus]

@MikeWeller I don't think we understand yet what is going wrong in your scenario (i.e. we don't have a repro and have not yet witnessed the failure, even randomly). It sounds like the main process is hitting a deadlock? Do all other features fail when this occurs? Could you attach a debugger to the Microsoft.VSCode.CPP.Extension.exe process with "symbolSearchPath" to "https://msdl.microsoft.com/download/symbols" to get a call stack? Does it repro with our latest 0.23.0-insiders2 (which should be identical to the pending 0.23.0 we plan to release soon)?

@Jacky-Lau Your issue sounds different (might be related to the multi-root issues #2107, #1073). The failure log is unrelated.

[MikeWeller]

Still happening to me on 0.23. Attaching VS to each of the 3 Microsoft.VSCode.CPP.Extension.exe processes I see shows pretty much the same thing:

Main Thread:

ntdll.dll!_NtReadFile@36�()
KernelBase.dll!ReadFile()
Microsoft.VSCode.CPP.Extension.exe!__read_nolock�()
Microsoft.VSCode.CPP.Extension.exe!__read�()
Microsoft.VSCode.CPP.Extension.exe!common_refill_and_read_nolock<char>()
Microsoft.VSCode.CPP.Extension.exe!__fgetc_nolock�()
Microsoft.VSCode.CPP.Extension.exe!_fgetc�()
Microsoft.VSCode.CPP.Extension.exe!std::_Fgetc<char>(char &,struct _iobuf *)
Microsoft.VSCode.CPP.Extension.exe!std::basic_filebuf<char,struct std::char_traits<char> >::uflow(void)
Microsoft.VSCode.CPP.Extension.exe!std::basic_filebuf<char,struct std::char_traits<char> >::underflow(void)

And a couple dozen of other threads waiting, e.g.

ntdll.dll!_NtWaitForMultipleObjects@20�()
KernelBase.dll!WaitForMultipleObjectsEx()
Microsoft.VSCode.CPP.Extension.exe!msvc::alertable_event::wait_for_multiple(class msvc::alertable_event * *,unsigned int,bool,unsigned int)
Microsoft.VSCode.CPP.Extension.exe!msvc::thread_pool::do_work(unsigned int)
Microsoft.VSCode.CPP.Extension.exe!std::_LaunchPad<std::unique_ptr<std::tuple<<lambda_a3c66ca3d4c2719be92bdb8d8b1f4c0e> >,std::default_delete<std::tuple<<lambda_a3c66ca3d4c2719be92bdb8d8b1f4c0e> > > > >::_Go()
Microsoft.VSCode.CPP.Extension.exe!std::_Pad::_Call_func(void *)
Microsoft.VSCode.CPP.Extension.exe!thread_start<unsigned int (__stdcall*)(void *)>()
kernel32.dll!@BaseThreadInitThunk@12�()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart@8�()

Or

ntdll.dll!_NtWaitForAlertByThreadId@8�()
ntdll.dll!RtlSleepConditionVariableSRW()
KernelBase.dll!_SleepConditionVariableSRW@16�()
Microsoft.VSCode.CPP.Extension.exe!___crtSleepConditionVariableSRW�()
Microsoft.VSCode.CPP.Extension.exe!Concurrency::details::stl_condition_variable_win7::wait_for(class Concurrency::details::stl_critical_section_interface *,unsigned int)
Microsoft.VSCode.CPP.Extension.exe!Concurrency::details::stl_condition_variable_win7::wait(class Concurrency::details::stl_critical_section_interface *)
Microsoft.VSCode.CPP.Extension.exe!do_wait()
Microsoft.VSCode.CPP.Extension.exe!__Cnd_wait�()
Microsoft.VSCode.CPP.Extension.exe!std::_Cnd_waitX(struct _Cnd_internal_imp_t *,struct _Mtx_internal_imp_t *)
Microsoft.VSCode.CPP.Extension.exe!std::condition_variable::wait<class <lambda_dd6003aba6786f0949aec7bd58cd9601> >(class std::unique_lock<class std::mutex> &,class <lambda_dd6003aba6786f0949aec7bd58cd9601>)
Microsoft.VSCode.CPP.Extension.exe!vscode::message_deque<int>::pop_impl(bool)
Microsoft.VSCode.CPP.Extension.exe!<lambda>(void)()
Microsoft.VSCode.CPP.Extension.exe!std::_LaunchPad<class std::unique_ptr<class std::tuple<class std::function<void > >,struct std::default_delete<class std::tuple<class std::function<void > > > > >::_Run(class std::_LaunchPad<class std::unique_ptr<class std::tuple<class std::function<void > >,struct std::default_delete<class std::tuple<class std::function<void > > > > > *)
Microsoft.VSCode.CPP.Extension.exe!std::_LaunchPad<class std::unique_ptr<class std::tuple<class std::function<void > >,struct std::default_delete<class std::tuple<class std::function<void > > > > >::_Go(void)
Microsoft.VSCode.CPP.Extension.exe!thread_start<unsigned int (__stdcall*)(void *)>()
kernel32.dll!@BaseThreadInitThunk@12�()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart@8�()

[Jacky-Lau]

@sean-mcmanus But I've tried to open in singe-root folder and clang format still won't work. It seems to have something to do with the log name C/C++.log which contains a slash.

[sean-mcmanus]

@MikeWeller Those call stacks are not doing any work (they're blocked waiting for work), i.e. not deadlocked threads. Usually, a call stack that is a deadlock will show a bunch of real work (i.e. a bigger call stack). Do you see any call stack that looks like it's doing actual work?

@Jacky-Lau The log issue is unrelated. It's #3604 .

[peeeeter]

@MikeWeller, @sean-mcmanus This has been plaguing me for several months. I kept assuming lots of people must experience this and it would get fixed very quickly. Can you give me some debug hints? When i attach to these processes I'm just in the middle of random asm. Did you download the source and do a debug build of the extension? (Is the source even available for this?)

[sean-mcmanus]

@peeeeter If you're on Windows you need to set "symbolSearchPath": "https://msdl.microsoft.com/download/symbols" in your launch.json config. You don't need a debug build or the source (which isn't available for the C++ processes), but it's possible the root cause is an open source TypeScript issue, particularly if you're using multiple workspace folders, which is not debugged via attaching to the language server process. If you enable debug logging you may be able to determine where the source of the problem is.

[peeeeter]

@sean-mcmanus I am indeed using multiple workspace folders. Thanks, I got it going... let's see if I turn up anything. Of course now it seems to be working for the last 15 minutes....

[peeeeter]

@sean-mcmanus Before stops working, format doc has tons of log activity and shows the I/O from clang-format and such. After stops working, symptom which I believe is consistent with @MikeWeller, is that there is no log activity. Pressing Ctrl-Shift-I simply has no effect and there is no log activity.

[peeeeter]

@sean-mcmanus Let me know if you have other ideas for debugging/more info I could provide. In some cases, formatting the document fails on the first try after restarting code and even just minor modifications to a file.

[cgw28716]

I also have the same issue and restart code will work for a while.
I find that each time it doesn't work, use "format document with" command and there are several c/c++ in the menu.

[Victsz]

@sean-mcmanus I dont really understand what multi-root workspace means, my workspace structure is as below. And the files are corrupting frequently.

[sean-mcmanus]

@Victsz Your issue could have a different cause. What is the [SSH: ...] next to the folder? It could be related to that. If you enable debug logging and you can look to make sure a didOpen message is sent for the same folder that gets the format or if there's some other error going on.

[kisielk]

Is there any progress or ETA on this issue at all? It's pretty critical to my workflow to the point where I'm looking at switching to a different programming environment because of the problems this has been causing.

[sean-mcmanus]

@kisielk No progress yet, but a lot of people are complaining about this, so I feel like it's something we should fix maybe for July/August.

[peeeeter]

Yeah, still not sure exactly how my issue relates, I haven't done any work to test single directory workspaces. I have recently confirmed that there's nothing in the log that's unusual when it stops working. You just don't see clang I/O any more. Intellisense other stuff still scrolls by as normal. It breaks all the time. I use Ctrl-Shift-I pretty much constantly, and I have to restart vscode every 5 minutes it feels like.

[sean-mcmanus]

@kisielk @peeeeter Have you tried setting C_Cpp.formatting to "Disabled" and using the clang-format extension instead?

@peeeeter Your issue might get fixed when we fix the multi-root issue...that would be the case if you see that the logs where formatting is occurring don't also show a didOpen message. Otherwise, we'd need to somehow get a repro or more diagnostics. The formatting runs on our "main thread" and basically just runs clang-format passing data via stdin/out, the results of which should appear in the debug logs.

[peeeeter]

Yes, I tried that, but The Ctrl-Shift-I key binding just doesn't work, and doesn't seem to work with the new extension. It just says: 

…

On Thu, Jun 20, 2019 at 6:09 PM Sean McManus ***@***.***> wrote: @kisielk <https://github.com/kisielk> @peeeeter <https://github.com/peeeeter> Have you tried setting C_Cpp.formatting to "Disabled" and using the clang-format extension instead? @peeeeter <https://github.com/peeeeter> Your issue might get fixed when we fix the multi-root issue...that would be the case if you see that the logs where formatting is occurring don't also show a didOpen message. Otherwise, we'd need to somehow get a repro or more diagnostics. The formatting runs on our "main thread" and basically just runs clang-format passing data via stdin/out, the results of which should appear in the debug logs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3145?email_source=notifications&email_token=AB776WOWULABQJTJPI2FYK3P3QS4BA5CNFSM4GWBNIW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYHELQQ#issuecomment-504251842>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB776WOOZWAVM466J74LZJ3P3QS4BANCNFSM4GWBNIWQ> .

[sean-mcmanus]

@peeeeter There is some bug with VS Code that is saving our extension as a the default formatter when it no longer a format provider (I wasn't able to repro it though). Other users have reported that using the "Configure Default Formatter..." to select "clang-format" fixes the issue.

[peeeeter]

@sean-mcmanus Your suggestion was a good start, but now I am blocked by xaverh/vscode-clang-format#83, so I still don't have a workaround. I am still experiencing the issue when I revert to the cpp tools implementation.

[sean-mcmanus]

@peeeeter That is odd. I know the clang-format extension requires you to manually download the clang-format program and set the path to it manually...it sounds like it's failing to find the clang-format binary.

[peeeeter]

@sean-mcmanus The EPIPE error was very generic and I just assumed that was the cause. With your hint I believe I solved the issue, a misplaced slash in the path.

[sean-mcmanus]

@peeeeter We just found/fixed a bug with named pipe creation not accessing static data in a thread safe manner which could lead to this EPIPE error (if another thread is trying to launch a process, such as for IntelliSense) -- it should be in our next release.

Or...if you're saying your path had a bad slash that could be a different issue?

[sean-mcmanus]

Our latest Insiders release has a new multi-root implementation (which fixes this bug): https://github.com/microsoft/vscode-cpptools/releases/tag/0.27.0-insiders. Please let us know if you find any multi-root-related bugs or regressions so we can prioritize fixing those for 0.27.0.

[jeremyong]

I'm encountering this bug on the latest VSCode and insiders CPP release. Clang format suddenly stops working until a restart. (not using multi-root)

[michelleangela]

@jeremyong, we had reports of Clang format issues in 0.27.0-insiders2 and have a fix in the next 0.27.0-insiders3.

Perhaps the issue you encountered is related to these:

• old Clang format 6.0.0 in 0.27.0-insiders2
• clang_format_sortIncludes ignores .clang-format setting at startup clang_format_sortIncludes ignores .clang-format setting at startup #5068