namespace named interface causes extension to loop infinitely

[junessi]

Issue Type: Performance Issue

Since some weeks this extension starts to run some processes to ocuppy cpu(2 - 4 cores) for inifite time, even if I left it run for the whole week, it never stop. Now my vscode hangs for some second after I type a word, it not possible for me to use this ext any more.

Extension version: 0.26.0
VS Code version: Code 1.39.2 (6ab598523be7a800d7f3eb4d92d7ab9a66069390, 2019-10-15T15:33:40.634Z)
OS version: Linux x64 4.4.0-165-generic

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (4 x 3408)
GPU Status	2d_canvas: unavailable_software flash_3d: disabled_software flash_stage3d: disabled_software flash_stage3d_baseline: disabled_software gpu_compositing: disabled_software multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software oop_rasterization: disabled_off protected_video_decode: disabled_off rasterization: disabled_software skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: disabled_software viz_display_compositor: disabled_off webgl: unavailable_software webgl2: unavailable_software
Load (avg)	4, 4, 4
Memory (System)	15.63GB (7.92GB free)
Process Argv	--unity-launch
Screen Reader	no
VM	100%

Process Info

CPU %	Mem MB	   PID	Process
    0	   160	 22271	code main
    0	    32	 22273	   zygote
    0	   464	 22315	     window (Extension: C/C++ - workspace0 (Workspace) - Visual Studio Code)
    0	   368	 22356	       extensionHost
    0	    64	 22419	         /usr/share/code/code /usr/share/code/resources/app/extensions/json-language-features/server/dist/jsonServerMain --node-ipc --clientProcessId=22356
   24	   128	 23152	         /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.Extension.linux
    0	   224	 25896	           /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.IntelliSense.Msvc.linux 23152 40
    0	   208	 26034	           /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.IntelliSense.Msvc.linux 23152 42
    0	   240	 26050	           /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.IntelliSense.Msvc.linux 23152 43
   24	    80	 23451	         /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.Extension.linux
   24	    32	 29407	         /home/user/.vscode/extensions/ms-vscode.cpptools-0.26.0/bin/Microsoft.VSCode.CPP.Extension.linux
    0	    48	 22390	       watcherService
    0	    96	 22357	     shared-process
    0	     0	 30491	       /bin/sh -c /bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=
    0	     0	 30492	         /bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=
    0	    80	 29873	     window (undefined)
    0	    96	 30469	     window (Issue Reporter)
    0	    48	 22307	   gpu-process

Workspace Info

|  Window (Extension: C/C++ - workspace0 (Workspace) - Visual Studio Code)
|    Folder (module1): 98 files
|      File types: hpp(34) cpp(31) txt(12) git(1) yml(1) in(1) NDS(1)
|      Conf files:
|    Folder (module2): 1086 files
|      File types: hpp(451) cpp(320) txt(99) md(2) ds(1) json(1) ini(1) yml(1)
|                  gitignore(1) cmake(1)
|      Conf files: cmake(1)
|    Folder (module3): 1519 files
|      File types: hpp(745) cpp(433) txt(96) dox(3) png(2) gitignore(1) in(1)
|                  yml(1) git(1) md(1)
|      Conf files:
|    Folder (module4): 2701 files
|      File types: hpp(1379) cpp(1181) txt(2) git(1) yml(1) md(1)
|      Conf files:;

[sean-mcmanus]

Can you enable debug logging (https://code.visualstudio.com/docs/cpp/enable-logging-cpp) and/or attach a debugger and view the call stacks. Or are the database or flame icons showing a status? One possibility is that you may have a symlink that points to some large directory, such as your root drive (see #3123). You could change the browse.path setting to include less folders (or use "*" to make the paths non-recursive).

[junessi]

Neither database nor flame icon was being shown. The is no symbol link in my directory. I reduced my project to one cpp file which has only 6 lines and was running with one core 100% usage, after I closed vscode, the extension was still running with one core 100% for infinite time, some time later even with two cores(both were running with 100% usage). I attached the process with gdb and saw the following backtraces:

Attaching to process 16538
[New LWP 16539]
[New LWP 16540]
[New LWP 16541]
[New LWP 16542]
[New LWP 16543]
[New LWP 16544]
[New LWP 16545]
[New LWP 16546]
[New LWP 16548]
[New LWP 16629]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f2c4683fd2d in __GI___pthread_timedjoin_ex (threadid=139828003849984, thread_return=0x0, abstime=0x0,
block=<optimized out>) at pthread_join_common.c:89
89 pthread_join_common.c: No such file or directory.
(gdb) bt
#0 0x00007f2c4683fd2d in __GI___pthread_timedjoin_ex (threadid=139828003849984, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:89
#1 0x0000000000c9bd93 in std::thread::join() ()
#2 0x00000000006683bf in vscode::message_handler::shutdown() ()
#3 0x0000000000668b7f in vscode::message_handler::shutdown(vscode::vscode_client_message const&) ()
#4 0x0000000000667105 in vscode::message_handler::main_loop() ()
#5 0x0000000000663073 in main ()

It seemed that a thread was busy and never end.

[sean-mcmanus]

The call stack shown is waiting for another thread to complete. Can you provide the call stack of the thread that is actually doing work?

Do you know what is triggering the shutdown? Are these dangling processes from a previous shutdown or do they appear again after opening the folder? Can you kill the processes?

[junessi]

I can kill the process with kill -9 PID. It is not from previous shutdown, because every time I killed all cpptools ext processes then started new analysis, and using kill -9 is the only way to shut it down. After debugging the the thread which runs for ever, I found the following callstack:

[Switching to thread 11 (Thread 0x7f0b71684700 (LWP 7188))]
#0  0x00007f0b76640e36 in __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:518
518	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) n
519	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
520	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
521	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
522	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
523	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
524	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
525	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
526	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
527	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
528	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
529	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
530	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
531	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
517	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
518	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
519	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
520	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
521	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) n
522	in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:522
#1  0x00000000006a5eb8 in vscode::message_handler::getDocumentSymbol(std::vector<browse_symbol, std::allocator<browse_symbol> >&) ()
#2  0x00000000006711e0 in vscode::message_handler::textDocument_documentSymbol(vscode::GetDocumentSymbolRequestParams) ()
#3  0x000000000067048c in vscode::message_handler::handle_symbol(vscode::vscode_client_message&&) ()
#4  0x00000000006b029d in std::_Function_handler<void (), vscode::message_handler::main_loop()::$_5>::_M_invoke(std::_Any_data const&) ()
#5  0x0000000000c9bb1f in execute_native_thread_routine ()
#6  0x00007f0b768aa6db in start_thread (arg=0x7f0b71684700) at pthread_create.c:463
#7  0x00007f0b765d388f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

this thread keeps looping from line 517 to 531 in file memmove-vec-unaligned-erms.S, it seems getDocumentSymbol() is reading the document without reaching the end.

I hope it will be helpful to you.

[sean-mcmanus]

This is a regression compared to 0.25.1, right? The getDocumentSymbol got changed with new code to handle nested scopes in the outline view. Unfortunately, the call stack doesn't show the line numbers so we're not sure where the memmove is being attempted.

This code gets run when a document opens and the problem should be specific to a particular document's text, i.e. it doesn't repro with a simple "void main(){}" file right? Are you able to isolate what code in the document is causing the bug and provide a code sample? We had some bugs previously with code that had nested namespaces.

[junessi]

The tests above were based on 0.26.0. Today I updated my extension to 0.26.1 and reduced my code to one line which still causes the issue:
my::name::space::interface::ClassA::Number n;

This line of code is global(not in any namespace nor function). If I remove the interface from the line:
my::name::space::ClassA::Number n;
Then this issue disappeared.

This behavior is reproducible in linux but not reproducible under windows.

[sean-mcmanus]

Thanks a lot -- we got a repro -- the usage of keyword "interface" is causing the problem.

[michelleangela]

Fixed in version 0.26.2-insiders, available at https://github.com/microsoft/vscode-cpptools/releases/tag/0.26.2-insiders.

[junessi]

After an observation of two weeks, this issue has not appeared any more.