Extension locks up when closing files on FUSE

          @sean-mcmanus (picking up from @jsimonlane's report with the same behavior)

C/C++ Extension v1.11.5
C/C++ Extension Pack v1.2.0
Linux (remote VS Code over SSH from a Windows VS Code instance)

The Debug logs don't seem to show anything particularly interesting, just regular logs when jumping to token definitions:

idle loop: reparsing the active document
Checking for syntax errors: /home/justinw/path/to/sources/sor_main.cc
Queueing IntelliSense update for files in translation unit of: /home/justinw/path/to/sources/sor_main.cc
textDocument/hover: /home/justinw/path/to/sources/sor_main.cc (id: 789)
Request canceled: 789
cpptools/finishUpdateSquiggles
Error squiggle count: 0
textDocument/definition: /home/justinw/path/to/sources/sor_main.cc (id: 790)
cpptools/getSemanticTokens: /home/justinw/path/to/sources/sor_main.cc (id: 791)
cpptools/getFoldingRanges: /home/justinw/path/to/sources/sor_main.cc (id: 792)
cpptools/getCodeActions: path/to/dependencies/dist/include/tslog.h (id: 793)
textDocument/didOpen: path/to/dependencies/dist/include/tslog.h

Here's the ps aux entry for a spinning cpptools-srv process:

justinw  1030006 75.6  0.7 5229968 432940 ?      Sl   18:35  11:40 /home/justinw/.vscode-server/extensions/ms-vscode.cpptools-1.11.5-linux-x64/bin/cpptools-srv 872753 {D26E0D8F-EB4F-44AD-9FDB-39007E7D5A24}

And here's a call stack for that cpptools-srv proccess, assuming I pulled it correctly:

Thread 35 (LWP 1040762):
#0  0x00000000007ec865 in void std::__introsort_loop<__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, long, __gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, __gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, long, __gnu_cxx::__ops::_Iter_less_iter) ()
#1  0x0000000000775287 in sqlite3Insert ()
#2  0x00007fe878243318 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 13 (LWP 1030018):
#0  0x00007fe879c4929c in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 12 (LWP 1030017):
#0  0x00007fe879c4600c in ?? ()
#1  0x00007fe84401a350 in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 11 (LWP 1030016):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000014 in ?? ()
#2  0x000000000000005a in ?? ()
#3  0x00007fe870ff8e20 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 10 (LWP 1030015):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000014 in ?? ()
#2  0x0000000000000059 in ?? ()
#3  0x00007fe8717f9e20 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 9 (LWP 1030014):
#0  0x00007fe879b7121f in ?? ()
#1  0x00000000ffffffff in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 8 (LWP 1030013):
#0  0x00007fe879c4635b in ?? ()
#1  0x000000000000077c in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (LWP 1030012):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x00007fe872ffccf0 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 6 (LWP 1030011):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000005 in ?? ()
#3  0x00007fe8737fdcf0 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 5 (LWP 1030010):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000006 in ?? ()
#3  0x00007fe873ffecf0 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 4 (LWP 1030009):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000003 in ?? ()
#3  0x00007fe878a46cf0 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 3 (LWP 1030008):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000001 in ?? ()
#3  0x00007fe879247cf0 in ?? ()
#4  0x0000000000000000 in ?? ()

Thread 2 (LWP 1030007):
#0  0x00007fe879c4600c in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 1 (LWP 1030006):
#0  0x00007fe879c4635b in ?? ()
#1  0x00000000000003bc in ?? ()
#2  0x0000000000000000 in ?? ()

Originally posted by @justin39 in https://github.com/microsoft/vscode-cpptools/issues/9774#issuecomment-1230721637

Reproduce the lockup when closing files on FUSE in the Linux remote VS Code setup, using the listed C/C++ Extension versions. Start with the debug logs and the spinning cpptools-srv process and call stack; done means closing files no longer leaves cpptools-srv spinning.