lldb-mi becomes unresponsive, uses lots of memory

[ftrofin]

OS: macOS Sierra (10.12.6)
Visual Studio Code Version 1.22.2
ms-vscode.cpptools 0.16.1

Sometimes, when debugging, VS Code UI becomes unresponsive after clicking "Continue" when stopped at a breakpoint. No matter how long I wait, it doesn't recover. Attached is a sample of lldb-mi process which was at 46GB of used memory and climbing. I waited about 20 minutes in this particular case.

Please let me know if you need more information.

Thanks!
F.
Sample of lldb-mi while debugging - using 45GB of memory.txt

[ftrofin]

Here is another sample taken in another debugging session. In the debug console it printed "
ERROR: LLDB exited unexpectedly with exit code 137 (0x89). Debugging will now abort." before aborting debugging. This sample was taken when lldb-mi was consuming about 27GB of memory, it crashed when it reached 46.
Sample of lldb-mi while debugging - using 30GB of memory.txt

[ftrofin]

Here are two more samples of lldb-mi. In this case the debugger is unresponsive (like before) but it's not consuming memory like in the above case (Activity Monitor reports a stable usage of about 4 GB of memory). The lldb-mi process is using one of the cores at 100%. Both samples are taken on the same process at a minute difference. The scenario was the same as above: stopped at breakpoints, continued a few times then it stopped responding after clicking "Continue".

Sample of lldb-mi - unresponsive while debugging-2.txt
Sample of lldb-mi - unresponsive while debugging.txt

[WardenGnaw]

Thank you for all the samples. This will help with the investigation.

Can you also provide the logs from engineLogging? It would be helpful to see what command it is failing on.

Since VS Code UI seems to freeze, the best way to capture the logs is by adding --engineLogging=<filePath> to .vscode/extension/ms--vscode.cpptools-<version>/out/src/Debugger/extension.js. In there you should find a line that looks like:

args: ['--interpreter=vscode']

modify it to say

args: ['--interpreter=vscode', '--engineLogging=<filePath>']

Replace <filePath> with wherever you would like the logs to be saved.

[ftrofin]

Hi Andrew. I don't know which .vscode folder you're referring to. There is one in my workspace but it only contains the launch, settings and tasks.json.

Also, to clarify, the UI is not frozen, I can click on the debugging toolbar (step over, continue, etc) and they look enabled but they don't do anything. I also experienced one or two cases where it recovered after a very long time (20+ minutes) and I was able to continue stepping. Maybe some operation is blocking the main thread during this time (hopefully the logs above are useful).

[WardenGnaw]

Ah sorry. The .vscode folder in home path. For OSX it should be ~/.vscode.

If its possible to interact with the debug console. Can you can add the following to your launch.json configuration and provide a copy of the output?

"logging": {
   "engineLogging": true
}

[sheldonneuberger]

I'm having this same issue. I tried adding the --engineLogging flag but it doesn't create the specified file. It looks like that codepath only runs on windows, but we're on macos.

I left the debugger running in the frozen state, and the next day (after closing/suspending my laptop several times), I noticed it successfully stepped into the line of code! Output from engineLogging: https://gist.github.com/sheldonneuberger/f774677efb87b79cfbed75d9be0c9aba

I've run lldb from the command line against this executable and I don't hit these issues, so it's something with vscode. This consistently repros for me, but not for one of my colleagues with a similar setup. I'll dig a bit to see if there's an obvious difference on our machines.

My lldb -v output is:

lldb-900.0.64
  Swift-4.0

[cedriclmenard]

I'm experiencing the same issue. Only when I build for Debug, not in Release (using CMakeTools).

[Samx2015]

This issue still exists as of 6/27/2020. VSCode on mac: lldb-mi uses 160GB of memory.

[spott]

I am also seeing this issue.

Let me know if there is anything that I can collect in order to help work this out.

[DEAGS3000]

Me too. VSCode on mac os 10.14.5, with lldb-mi in cpp-tools extension. this will only happen when I'm trying to do step over in a certain member function.

[blanerhoads]

Me three

[ph0ngp]

me four. lldb-mi currently using 56GB of memory here. This sometimes happen when I try to step into a certain member function. And sometimes it just works normally, so weird.

[lincoln310]

me five.

[WardenGnaw]

The VSCode C++ Extension does not directly work on lldb or lldb-mi. We use and build lldb-mi from the lldb-mi repository and publish it.

We build the debug adapter MIEngine to communicate with lldb-mi, but that will be in the OpenDebugAD7 process.

If memory usage is high for the lldb-mi process, this is directly related to LLDB itself which you can report bugs to https://bugs.llvm.org/

You can capture and send trace files to help them investigate performance issues. Here is a tutorial on how to capture a trace file but for cpptools and cpptools-srv. You will want to capture the trace on lldb-mi.

[ShadyBoukhary]

Me six. 30+ GB of memory used. I have to constantly manually kill the process.

Has anyone reported a bug to https://bugs.llvm.org/ ?

[WardenGnaw]

Closing due to being an external issue with lldb-mi.

[FuXiii]

This issue still exists 2022/4/4
microsoft/vscode#146655 (comment)

[kengran]

Is there a temp fix/get-around? Very annoying..

[ShadyBoukhary]

@kengran place the breakpoint somewhere else

[mikkqu]

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> a{ 1, 1, 1, 1, 1 };
    std::vector<int> b{ 1, 1, 1, 1, 1 };
    std::vector<int> c{ 1, 1, 1, 1, 1 };

    return 0;
}

It hangs when I'm trying to debug something as simple as this. Might be the easiest way to reproduce.

[foragerDev]

I was debugging simple program, and it eaten up to 45 GB or RAM. And I had to restart applications.

[rdlaner]

I am also having this issue, it is preventing me from running the debugger for any of my c/c++ code. Is there any work-around or an alternative to lldb-mi that can be used?

[xsaschako]

This issue persists for me and i encounter it quite often.

[wxquare]

Is there any ways to fix it?

[wibbeler]

I've seen VSCode create multiple lldb and lldb-mi processes without cleaning them up. Often, they are left unresponsive and take a lot of memory. I think this is happening when trying to inspect large stl containers (eg a list with many items). Closing VSCode did not stop the lldb* processes. I had to kill them in the Activity Monitor.

[arunmudhaliar]

It's a mess... taking 22GB. it keeps on increasing.... and my machine starts to shy away...

[piaopiaoquan]

i am using vs code in mac, the lldb-mi is like dead frequently when debugging , and the memory it taked increaing