cpptools extension using excessive memory in 0.28.1 in linux

[shammabeth]

Type: General

Version 0.28.1 of cpptools uses excessive memory (56+ GB!!!!).
I am opening a folder that has 5000+ files. My system has 64GB or system RAM and a 1TB swap file on a regular disk.

I switched back to 0.28.0 and memory usage is back to normal (3.3 GB)

Describe the bug

• OS and Version: Linux Ubuntu 16.04
• VS Code Version: 1.45.1
• C/C++ Extension Version: 0.28.1
• Other extensions you installed (and if the issue persists after disabling them): n/a
• A clear and concise description of what the bug is.

Version 0.28.1 of cpptools uses excessive memory (56+ GB!!!!).
I work in a folder tree that has 5000+ files . My system has 64GB or system RAM and a 1TB swap file on a regular disk. I noticed system perf degradation caused by excessive use of swap partition. System monitor revealed cpptools using around 56GB. I've tried killing, restarting, rebooting the system.

Eventually I switched back to 0.28.0 of cpptools and memory usage is back to normal (3.3 GB)

To Reproduce
Steps to reproduce the behavior:

1. Open a massive project folder that has 5000 to 10000 files
2. Simulate normal work patterns by keeping on opening different files. I usually have 300+ editors open.
3. Observe memory usage for cpptools

Expected behavior
Memory usage for cpptools should be less than 5GB

Screenshots

Additional context
Downgrading to 0.28.0 fixes this issue. So it seems like something got introduced in 0.28.1 that's causing this.

[sean-mcmanus]

I assume it repros with 0.28.2 too?

We considered the 0.28.1 changes to be small in scope and "safe" -- I'll double check for anything that could cause this...

[sean-mcmanus]

Can you confirm whether the memory usage is from cpptools or the child cpptools-srv processes?

So far we're unable to repro the issue and don't see any change from 0.28.1 that could be causing this.

[sean-mcmanus]

Also, is stuff otherwise functioning or does there appear to be a deadlock or other issue?

What actions appear to be causing the memory usage to rise? Does it rise if you just open 1 .cpp file or does it gradually rise the more files that are open? Are edits or other actions required?

[sean-mcmanus]

0.28.1 fixed a high hitting IntelliSense crash with the cpptools-srv process -- so now it could be hitting a new memory issue that was not hittable previously due to the blocking crash. The tool you're using to view memory usage may be reporting the child cpptools-srv process memory usage under cpptools.

If you close all the editors, does the memory free up? Does setting the C_Cpp.intelliSenseEngine setting to "Tag Parser" fix the memory issue (that disables the cpptools-srv processes from launching, not recommended due to reduced functionality).

[shammabeth]

Hi Sean, Thanks for the prompt response. I believe it was from the child cpptools-srv processes. One particular thing. Shutting down VSCode and restarting did not fix it. I had to manually kill the processes. There was no deadlock, but there was significant system perf degradation as it was constantly paging in and out of the swap partition. My regular use is opening the root folder that has a tree with around 5000+ files and continuing to work in that. I never close a file that I open. My editor is set to not reuse a tab. i.e. every file I open via the quick open action goes into a new tab unless its already available in a tab. The number of tabs range from 200-500 in regular use. I use intellisense a lot (2 features in particular, header/source file flip and go to definition). I use the timeline feature at times and look at diffs. I also use source control integration to look at diffs, and sometimes to stage files. When using it takes around a few hours before I start to see the degradation of performance which is usually a lot of hitches and stalling system wide. I don't think closing editors frees up memory. I tried that at some point. In fact, closing VS Code leaves dangling cpptools and cpptools-srv. I can later try the tag parser and see if that helps. Is there anyway to setup a log file or status dump that I can send your way? - Shammi

…

On Wed, Jun 3, 2020 at 4:13 PM Sean McManus ***@***.***> wrote: 0.28.1 fixed a high hitting IntelliSense crash with the cpptools-srv process -- so now it could be hitting a new memory issue that was not hittable previously due to the blocking crash. The tool you're using to view memory usage may be reporting the child cpptools-srv process memory usage under cpptools. If you close all the editors, does the memory free up? Does setting the intelliSenseEngine to "Tag Parser" fix the memory issue (that disables the cpptools-srv processes from launching). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOLYVLWR5MKCQQ2EUMWTMLRU3KLBANCNFSM4NQ7HHZA> .

[sean-mcmanus]

The normally expected behavior is that on startup, one cpptools-srv will be launched for the active file, and then as you switch to other open documents, additional cpptools-srv should spawned for each new TU (.cpp file) up to your logical processor count, afterwhich the oldest used cpptools-srv should be closed -- do you see that happening or does the cpptools-srv count keep increasing endlessly?

Closing VS Code is supposed to kill the cpptools process and the cpptools-srv process -- does the dangling process issue occur every time for you? We've heard other users hitting this after upgrading their extension, but if it's happening more often then that's a new issue.

Using the "Tag Parser" should fix the memory issue, but it's not recommended since the features you use may not work (i.e. only global symbols will be available with no TU-based info).

[shammabeth]

So I installed 0.28.2 today and restarted. I notice 4 cpptools-srv processes open each taking up max of 200 MB However cpptools process is the culprit. I just reloaded VSCode (in order to reactivate updated cpptools extension) and since then its been constantly chewing up memory. I can see it increase around 100MB per second. Started at 6.2 GB (which is normal) and now at 20 GB and constantly increasing. Any other details I can provide you?

…

On Wed, Jun 3, 2020 at 5:48 PM Sean McManus ***@***.***> wrote: The normally expected behavior is that on startup, one cpptools-srv will be launched for the active file, and then as you switch to other open documents, additional cpptools-srv should spawned for each new TU (.cpp file) up to your logical processor count, afterwhich the oldest used cpptools-srv should be closed -- do you see that happening or does the cpptools-srv count keep increasing endlessly? Using the "Tag Parser" should fix the memory issue, but it's not recommended since the features you use may not work (i.e. only global symbols will be available with no TU-based info). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOLYVPLUK2TKKE473HSHCTRU3VNTANCNFSM4NQ7HHZA> .

[shammabeth]

So I reverted back to 0.28.0 and reloaded. The cpptools process spawned by 0.28.2 did not get killed and was still resident in memory. It stopped growing though, but was still holding onto its memory (~25 GB, which is when I decided to stop). I had to manually kill it.

…

On Thu, Jun 4, 2020 at 9:46 AM Shammi Mohamed ***@***.***> wrote: So I installed 0.28.2 today and restarted. I notice 4 cpptools-srv processes open each taking up max of 200 MB However cpptools process is the culprit. I just reloaded VSCode (in order to reactivate updated cpptools extension) and since then its been constantly chewing up memory. I can see it increase around 100MB per second. Started at 6.2 GB (which is normal) and now at 20 GB and constantly increasing. Any other details I can provide you? On Wed, Jun 3, 2020 at 5:48 PM Sean McManus ***@***.***> wrote: > The normally expected behavior is that on startup, one cpptools-srv will > be launched for the active file, and then as you switch to other open > documents, additional cpptools-srv should spawned for each new TU (.cpp > file) up to your logical processor count, afterwhich the oldest used > cpptools-srv should be closed -- do you see that happening or does the > cpptools-srv count keep increasing endlessly? > > Using the "Tag Parser" should fix the memory issue, but it's not > recommended since the features you use may not work (i.e. only global > symbols will be available with no TU-based info). > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#5602 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABOLYVPLUK2TKKE473HSHCTRU3VNTANCNFSM4NQ7HHZA> > . >

[shammabeth]

More info on the bug..
Also happens in 0.28.2

It's the cpptools process (not cpptools-srv) that ends up using excessive RAM. After launch I noticed it continuously consume more memory (around 100MB/sec). It starts at around 6.2 GB of usage and then constantly keeps increasing at that rate.

Let me know if I can turn on any logging and attach specific log files.

[sean-mcmanus]

Is cpptools also using CPU? Does the CPU usage ever end? If you set C_Cpp.loggingLevel to "Debug" does it show any output?

[letmaik]

$ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                             
13040 user 20   0 28.553g 0.025t 0.007g S 100.0 83.1  17:54.86 cpptools                                            
15222 user 20   0  4.667g 0.107g 0.015g S  13.3  0.3   0:06.46 cpptools-srv

It uses nearly all of my 32 GiB of memory.

[sean-mcmanus]

@letmaik Do you have any more repro details? We would like to fix that, but need more info and/or a repro.

[seyfullahari]

It looks like exclude filters (files.exclude and search.exclude) are skipped when building the cache or parsing the files.

I have a build tree that contains a huge temp folder (~80K files, ~30GB data). It contains mainly c/c++ files and build outputs. This folder is excluded by the filters and not visible in the explorer.

cpptools uses around 16GB when this folder is part of the workspace. Doesn't matter if it is filtered or not. On the other hand when I delete this folder everything is OK. cpptools only use 50MB.

[sean-mcmanus]

@seyfullahari We do check files.exclude and skip parsing files under that, but we only work with glob patterns that are folders unless the C_Cpp.exclusionPolicy is changed (for performance reasons). Can you make sure your glob pattern matches to a folder and not files under the folder? If you set your C_Cpp.loggingLevel to "Debug" you can see more info on what files we are tag parsing (to see if the excluded ones are being parsed or not). There is also a hidden logging level of "9" that will output info on the exclusions that are being processed, but that level is highly verbose and not recommended to be used often. It's also possible there is something special about your scenario that is breaking our exclusion mechanism, i.e. if symlinks are used, we may not match the paths correctly for exclusion purposes -- see #4206. If you can provide more repro info maybe we can figure out the cause.

[seyfullahari]

My workspace is located at /home/.../.../projectX
There are several subfolders below this folder, and one of them is tmp, which is huge.
One of my Files:exclude filters is **/tmp
C_Cpp:Exclusion Policy is set to checkFolders

When I enable loglevel 9, I see thousands of logs for files located below the tmp folder. It is very obvious that tmp is being traversed. I don't see any parsing or regex match related logs. These logs are available for files that don't match the exclude filters.

After 5 min of running cpptools hits ~20GB resident mem size.
Why is tmp folder traversed at all, should it just not be skipped?

[sean-mcmanus]

@seyfullahari I'm not able to repro the bug (and we haven't received other bug reports like this). You should see logging like:

pattern_matcher::matches(): **/tmp -> "(?:.*tmp)(?:(/.*|$))"
  normalized file path: /<path>/tmp
  subpath under root: tmp
  Regex matches, no filter

My best guess is that a symlink exists that targets the a location under tmp.

If you could provide a sample repro project that could help diagnose what is going wrong.

You should still see files under tmp in the logs due to issue #3123 (i.e. our code that iterates over the files in a directory doesn't check the files.exclude until later, causing all the excluded files to be added to a vector), but that issue shouldn't cause the files to be added to the database, i.e. you shouldn't see update_file_if_needed: <path>/tmp/<file>.

[shammabeth]

cpptools uses around 2% CPU consistently. What are you looking for in the debug log?

…

On Thu, Jun 4, 2020 at 3:52 PM Sean McManus ***@***.***> wrote: Is cpptools also using CPU? Does the CPU usage ever end? If you set C_Cpp.loggingLevel to "Debug" does it show any output? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOLYVKC772HV2K522XMXQ3RVAQRNANCNFSM4NQ7HHZA> .

[shammabeth]

Good news. 0.28.3 seems to be a lot more stable with regards to usage of runaway memory usage for cpptools. Memory usage seems to be stable at around 7.7 GB right now and holding there as I keep opening new or switch to differnt .cpp file editors. There seems to be a constant 2% usage. Rarely I see it go to 3%. Earlier (0.28.1 and 0.28.2), the same workspace and repro steps would cause a constant increase of around 100MB/sec for cpptools. Not sure what your team did, but it looks like the issue is fixed in 0.28.3

…

On Mon, Jun 15, 2020 at 2:16 PM Shammi Mohamed ***@***.***> wrote: cpptools uses around 2% CPU consistently. What are you looking for in the debug log? On Thu, Jun 4, 2020 at 3:52 PM Sean McManus ***@***.***> wrote: > Is cpptools also using CPU? Does the CPU usage ever end? If you set > C_Cpp.loggingLevel to "Debug" does it show any output? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#5602 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABOLYVKC772HV2K522XMXQ3RVAQRNANCNFSM4NQ7HHZA> > . >

[sean-mcmanus]

@shammabeth FYI, the binary cpptools is identical with 0.28.1 to 0.28.3 (and the TypeScript changes are unlikely to impact the behavior).

[shammabeth]

Alright I can confirm for sure that in my case 0.28.3 fixes the issue.

I downgraded to 0.28.2 and noticed the following

• Memory usage increased quickly and steadily at around 100 MB/sec whether I opened editors or not
• Memory usage kept increasing past 8GB and kept increasing steadily
• CPU usage was around 4%

I reupgraded 0.28.3 and in comparison noticed the following

• Memory usage has stabilized at 1GB initially and has rare increments as I keep using.
• The previous time I used 0.28.3 where I kept opening new cpp editors, memory usage hit a max of 7.7 GB and stayed at that for well over an hour of normal use.
• CPU usage was for the most 2%, rarely spiking to 3%

I had logging set to debug, and did not notice much difference between the 2 sessions. I did not know what I was looking for specifically in the log messages. So, it's likely that I'm missing something with that observation, but for the most the log messages seemed similar.

[baiwfg2]

I met the same problem, 0.29.0. I launch multiple vscode windows, and it seems that cpptools has taken most of the memory

[gaodingpan]

I have also encountered this problem:
cpp tools version: 1.0.0
environment: ssh remote development from Windows to Linux(Ubuntu)

I am quite sure its from cpptools:

Please let me know if there is any other information I can provide, my team has several member using vscode and cpptools, and we have to frequently reload the window/kill the cpptools process to let our server continue functioning.

[sean-mcmanus]

@gaodingpan Yeah, we need a repro or some diagnostic logging that shows the call stack which is allocating the memory. The output of C/C++: Log Diagnostics may also help. Also, if anything can be changed to avoid the memory usage that could help isolate which system is causing the problem, such as if you add:

            "compilerPath": "",
            "browse": {
                "path": []
            }

and do a Reset IntelliSense Database command from the Command Palette.

[Vestaia]

Similar issue in current version (1.49.2) on MacOS 10.14.6. cpptools continuously allocates memory until system freezes (14GB). It also uses ~200% CPU when idle.

[github-actions]

Hey @sean-mcmanus, this issue might need further attention.

@shammabeth, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[JohnRThomas]

Still seeing this on version 1.2.0 (Jan 14th release)
cpptools using 10% CPU with no editors open, growing 100mb/s in memory.

I should note that I am using the Remote Development extension as well and cpptools is running on the remote server.

[sean-mcmanus]

@JohnRThomas We haven't been able to find a repro, so a fix would not be expected with 1.2.0-insiders2. If anyone can attach a debugger while memory is increasing fast and get a call stack that could help isolate what code is causing the issue: see https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv .

[JohnRThomas]

Thread 16 (Thread 0x7f2197fff700 (LWP 51249)):
#0  0x00007f2399410ab2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00000000007a48e1 in vscode::message_deque<vscode::vscode_client_message, false>::try_pop_front(vscode::vscode_client_message&, std::chrono::duration<long, std::ratio<1l, 1000l> >) ()
#2  0x000000000076d102 in _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN6vscode15message_handler9main_loopEvE3$_3EEEEE6_M_runEv
    ()
#3  0x0000000000ee5170 in execute_native_thread_routine ()
#4  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 15 (Thread 0x7f2191bfe700 (LWP 51250)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a50c8 in vscode::message_deque<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, false>::pop_impl(bool) ()
#3  0x000000000076e3dd in _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN6vscode15message_handler9main_loopEvE3$_4EEEEE6_M_runEv
    ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 14 (Thread 0x7f218b7fd700 (LWP 51251)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a5d79 in vscode::message_deque<vscode::folding_ranges_params, false>::pop_impl(bool) ()
#3  0x000000000076ebfd in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_6>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 13 (Thread 0x7f21853fc700 (LWP 51252)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a56be in vscode::message_deque<vscode::browse_engine_update_action, false>::pop_impl(bool) ()
#3  0x000000000076e4af in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_5>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 12 (Thread 0x7f217effb700 (LWP 51498)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a6267 in vscode::message_deque<vscode::vscode_client_message, false>::pop_impl(bool) ()
#3  0x000000000076ecbd in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_7>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 11 (Thread 0x7f2178bfa700 (LWP 51499)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a6267 in vscode::message_deque<vscode::vscode_client_message, false>::pop_impl(bool) ()
#3  0x000000000076ee7d in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_8>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 10 (Thread 0x7f21727f9700 (LWP 51500)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a6517 in vscode::message_deque<vscode::message_handler::parse_file_entry, true>::pop_impl(bool) ()
#3  0x000000000076f05f in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_9>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 9 (Thread 0x7f216c3f8700 (LWP 51501)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a6267 in vscode::message_deque<vscode::vscode_client_message, false>::pop_impl(bool) ()
#3  0x000000000076f7c7 in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_10>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7f2165ff7700 (LWP 51502)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x00000000007a6d9e in vscode::message_deque<int, false>::pop_impl(bool) ()
#3  0x000000000076f98d in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_11>::_M_invoke(std::_Any_data const&) ()
#4  0x0000000000ee5170 in execute_native_thread_routine ()
#5  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7f215fbf6700 (LWP 51503)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#1  0x0000000000e7190c in std::condition_variable::wait(std::unique_lock<std::mutex>&) ()
#2  0x000000000076fa7b in std::_Function_handler<void ()(), vscode::message_handler::main_loop()::$_12>::_M_invoke(std::_Any_data const&) ()
#3  0x0000000000ee5170 in execute_native_thread_routine ()
#4  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7f1fd3fff700 (LWP 55032)):
#0  0x00007f2399412f7d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f2399410f10 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#2  0x0000000000e71949 in std::condition_variable::notify_all() ()
#3  0x0000000000dcb7c8 in msvc::channel_manager_t::~channel_manager_t() ()
#4  0x00000000006f53dc in std::__shared_ptr<msvc::channel_manager_t, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() ()
#5  0x00007f239907d269 in __run_exit_handlers () from /lib64/libc.so.6
#6  0x00007f239907d2b5 in exit () from /lib64/libc.so.6
#7  0x0000000000bb9c62 in exit_compilation(an_error_severity) ()
#8  0x0000000000a4b6dd in cfe_main(int, char**) ()
#9  0x0000000000d5f0e6 in cfe_main_exception_handler(int, char**) ()
#10 0x0000000000a4b6f6 in edg_main(int, char**) ()
#11 0x0000000000a01495 in antlr_parse_routine() ()
#12 0x0000000000ee5170 in execute_native_thread_routine ()
#13 0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7f1fbffff700 (LWP 55113)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e5c096 in uv_cond_wait ()
#2  0x0000000000e4f526 in worker ()
#3  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f1fb9bfe700 (LWP 55114)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e5c096 in uv_cond_wait ()
#2  0x0000000000e4f526 in worker ()
#3  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f1fb37fd700 (LWP 55115)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e5c096 in uv_cond_wait ()
#2  0x0000000000e4f526 in worker ()
#3  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f1fad3fc700 (LWP 55116)):
#0  0x00007f2399410705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000e5c096 in uv_cond_wait ()
#2  0x0000000000e4f526 in worker ()
#3  0x00007f239940cdf3 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f239913a2cd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f2399b2d740 (LWP 51207)):
#0  0x00007f239940df37 in pthread_join () from /lib64/libpthread.so.0
#1  0x0000000000ee53a3 in std::thread::join() ()
#2  0x0000000000a01215 in tag_parse_shutdown() ()
#3  0x0000000000a015e2 in a_tag_parse_thread::~a_tag_parse_thread() ()
#4  0x00007f239907d269 in __run_exit_handlers () from /lib64/libc.so.6
#5  0x00007f239907d2b5 in exit () from /lib64/libc.so.6
#6  0x0000000000bbbd62 in term_on_signal(int) ()
#7  <signal handler called>
#8  0x00007f239912bb1b in read () from /lib64/libc.so.6
#9  0x00007f23990bc868 in __GI__IO_file_underflow () from /lib64/libc.so.6
#10 0x00007f23990bd7de in __GI__IO_default_uflow () from /lib64/libc.so.6
#11 0x00007f23990b8ab7 in getc () from /lib64/libc.so.6
#12 0x0000000000ea366d in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::underflow() ()
#13 0x0000000000e66f5a in std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) ()
#14 0x0000000000719a9c in vscode::message_handler::main_loop() ()
#15 0x0000000000715258 in main ()

[sean-mcmanus]

@JohnRThomas Those call stacks don't show any work being done that could be accumulating memory -- looks like it's shutting down or something. Usually, the call stack that is doing "real work" and accumulating memory would be deeper than 15 frames. Are you sure you attached to the cpptools process that was using lots of CPUs? Also, you may want to use https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.0-insiders2 due a fix for a bug that could cause cpptools to exit after the debugger was attached on Mac (as well as other bug fixes).

[github-actions]

This issue has been closed automatically because it needs more information and has not had recent activity.