Microsoft.VSCode.CPP.IntelliSense.Msvc.linux at 100% CPU for hours

[eskild]

(I already posted this in another bug, but was kindly asked to file it differently. I hope this is good; it's my first report re. vscode.)

Ubuntu 14.04. VSCode 1.17.1. C++ extension 0.13.1. Disabling other extensions doesn't seem to affect problem.

I work with a source tree of around 1500 files of mixed C/C++.

Problem: ~/.vscode/extensions/ms-vscode.cpptools-0.13.1/bin/Microsoft.VSCode.CPP.IntelliSense.Msvc.linux runs at 100% continuously, and IntelliSense barely works.

I've now resorted to a small script that'll kill all such processes. Then it'll run and IntelliSense will be usable for a few minutes, and then we're back at 100%

I finally got annoyed enough to attach gdb to the offending thread and got this trace; maybe it inspires some ideas. It smells like endless looping, perhaps due to wrong error handling in file I/O. I've frequently seen code that doesn't get error handling entirely right when, for example, a file disappears under its feet and where it just keeps looping, trying to read from a file that no longer provides data. Particularly with sub-processes.

In my usecase I compile frequently, and part of our build process generates new C++ files that are then compiled into the final images. I wouldn't be surprised if VSCode got surprised about this "flapping" of files.

All the other threads sit seemingly idle in futex waits. Some of them probably waiting for this one.

#0  0x000000000073b3f9 in source_file_for_seq ()
#1  0x000000000089982d in an_error_ptr_cmp::operator()(an_error* const&, an_error* const&) const ()
#2  0x000000000089ae52 in an_error_manager::get_errors(std::__1::vector<an_error*, std::__1::allocator<an_error*> >&) ()
#3  0x000000000053c6bd in edge::scoped_query_manager::get_filtered_errors_for_tu(edge::list<edge::error*>*, bool (*)(edge::error const&)) ()
#4  0x000000000054484d in edge::an_edge_translation_unit_impl::get_filtered_errors_for_tu(edge::allocator*, edge::snapshot_session const*, bool (*)(edge::error const&), edge::isense_error_array*) ()
#5  0x000000000050c2f0 in edge_intellisense_server_impl::handle_get_errors(microsoft::cpp::intellisense::GetErrorsRequest const&) ()
#6  0x0000000000530c0d in work_queue::worker_proc() ()
#7  0x000000000052d323 in std::__1::__function::__func<microsoft::vc::thread_pool::enqueue(std::__1::function<void ()>, std::__1::future<void>*)::{lambda()#1}, std::__1::allocator<{lambda()#1}>, void ()>::operator()() ()
#8  0x00000000008bddbd in microsoft::vc::thread_pool::thread_pool(int)::{lambda()#1}::operator()() const ()
#9  0x00000000008bdbad in void* std::__1::__thread_proxy<std::__1::tuple<microsoft::vc::thread_pool::thread_pool(int)::{lambda()#1}> >(std::__1::tuple<microsoft::vc::thread_pool::thread_pool(int)::{lambda()#1}>) ()
#10 0x00007f058bdcc184 in start_thread (arg=0x7f0583fff700) at pthread_create.c:312
#11 0x00007f058baf1ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[ihalip]

Happens to me too, and I think only 0.13.1 has this issue.

[bobbrow]

We have gotten reports of crashes at that call site, but nothing we've been able to reproduce in our offices. Do you or any of the "thumbs up" responders have an open source project, or small repro that we can use to investigate this?

If the CPU is at 100% forever, then it is likely an infinite loop somewhere in the IntelliSense engine, not a crash though. The only loops in this particular call stack involve an error list that is capped at 1000 entries by default. If you grabbed this call stack shortly after opening or editing a file, it could still be in the process of reporting the error squiggles which is normal behavior. If you leave the VS Code editor alone for a while and grab the call stack again, do you get the same thing?

[eskild]

My stack was taken once, after more than 17 hours of CPU time. Didn’t take it again after that. Will try to get more data.

…

Den 19. okt. 2017 kl. 22.06 skrev Bob Brown ***@***.***>: We have gotten reports of crashes at that call site, but nothing we've been able to reproduce in our offices. Do you or any of the "thumbs up" responders have an open source project, or small repro that we can use to investigate this? If the CPU is at 100% forever, then it is likely an infinite loop somewhere in the IntelliSense engine, not a crash though. The only loops in this particular call stack involve an error list that is capped at 1000 entries by default. If you grabbed this call stack shortly after opening or editing a file, it could still be in the process of reporting the error squiggles which is normal behavior. If you leave the VS Code editor alone for a while and grab the call stack again, do you get the same thing? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[eskild]

One thing, maybe, is that our source tree uses symlinking from one tree to another, and Code/CPP does tend to get a bit confused about that sometimes. (Please note that there is no symlink recursion.)

   repo1_dir
      ...many files and dirs...
   repo2_dir
      symlink to ../repo1_dir
      ...many files and dirs...

[sean-mcmanus]

@eskild Your call stack with source_file_for_seq matches a crash we're seeing (somewhere around our 3rd highest hitting crash), but it doesn't directly contain any loops, so I'm not sure how the crash and the infinite processing are connected.

[liyichao]

In mac, Version 0.14.0，cpu is also 100%，it is 100% since some versions, but I can not remember which:

[eskild]

Status update: I've been running 0.14.0 with VSCode 1.17.2 for a couple days now, and so far the problem I reported has not shown itself. With a little luck, it may have been fixed by the indexer work for 0.14.0.

I'll leave this issue open for a few days, and then close it if all remains well.

[ihalip]

I'm also running vscode 1.17.2 with ms-vscode.cpptools 0.14.0 and I still see the same issue.

Right now, I'm working in a directory with ~8000 source files and ~9000 headers and I see 2 Microsoft.VSCode.CPP.Extension.linux processes taking 100% CPU. Seems like most of the work is being done in a thread that parses files and stores info in an sqlite database.

[bobbrow]

@ihalip, there should only be one instance of Microsoft.VSCode.CPP.Extension.linux running if you only have one instance of VS Code running. Can you close VS Code, kill the lingering processes and try again? I wonder if the old 0.13.1 process didn't get shut down during the update.

[ihalip]

That didn't seem to help. The same thread is completely hogging 1 CPU core.

[eskild]

@ihalip You could try and enable logging to see if the indexing progresses. From the cpptools release note:

Add logging to Output window. Errors will be logged by default. Verbosity is controlled by the "C_Cpp.loggingLevel" setting.

I use "C_Cpp.loggingLevel": "Information"; it provides some amount of progress info, even if it isn't a) terribly detailed and b) time-stamped (@bobbrow, would be useful :-)

It's fair enough that the extension spends some time, maybe a few minutes, busily working, but when we get into two-digit minutes, something starts to smell suspect for common project sizes. Even NetBeans is quicker, then...

[sean-mcmanus]

@ihalip 1 minute of high CPU usage on 1 thread is not an indication of a bug. We need to know what it says on the tooltip on the database icon in the bottom right or if there's some error in the files that are being processed (as seen via the logging).
@eskild Long parse times can occur if it tries to recursively parse all the system headers.