Closed davkean closed 3 years ago
Hi @davkean,
thank you very much for bringing that up. I wasn´t aware of the huge memory consumption / issues that BuildVision is causing.
I´ll check the PR in the next hour :) Thanks a lot.
If there is anything else that you have noticed while debugging / perfchecking please let me know.
Hey, I'm from the Visual Studio performance team @ Microsoft.
We automatically capture data from Visual Studio instances with runaway thread and memory leaks, and BuildVision is showing up a top leak due to the following call stack:
Here we have a ThreadPool thread firing up based on a timer and trying perform a COM RPC to the UI thread to query a service. While the UI thread is busy, this thread will block waiting while the timer continues to fire, continually adding threads that are blocked. In some dumps we have, this stack is consuming over 700 threads, and sometimes up to 1600 threads. This leaks quite a lot of memory:
This code should be changed to only ever have one of these events running at the same time and should not assume that any GetService or access to IVsXXX will respond immediately. We have more information about this situation here: https://github.com/microsoft/vs-threading/blob/main/doc/threadpool_starvation.md.