Repository navigation
lldb-mi becomes unresponsive, uses lots of memory #1899
Description
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
Activity
ftrofin commentedon Apr 28, 2018
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 commentedon May 1, 2018
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 commentedon May 2, 2018
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:modify it to say
Replace
<filePath>with wherever you would like the logs to be saved.ftrofin commentedon May 2, 2018
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 commentedon May 2, 2018
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?
sheldonneuberger commentedon May 22, 2018
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:
cedriclmenard commentedon Sep 11, 2018
I'm experiencing the same issue. Only when I build for Debug, not in Release (using CMakeTools).
Samx2015 commentedon Jun 27, 2020
This issue still exists as of 6/27/2020. VSCode on mac: lldb-mi uses 160GB of memory.
spott commentedon Jul 17, 2020
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 commentedon Jul 19, 2020
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 commentedon Jul 29, 2020
Me three
lincoln310 commentedon Sep 1, 2020
me five.
WardenGnaw commentedon Sep 1, 2020
The VSCode C++ Extension does not directly work on
lldborlldb-mi. We use and buildlldb-mifrom the lldb-mi repository and publish it.We build the debug adapter
MIEngineto communicate withlldb-mi, but that will be in theOpenDebugAD7process.If memory usage is high for the
lldb-miprocess, 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
cpptoolsandcpptools-srv. You will want to capture the trace onlldb-mi.10 remaining items
xsaschako commentedon May 12, 2023
This issue persists for me and i encounter it quite often.
wxquare commentedon May 31, 2023
Is there any ways to fix it?
wibbeler commentedon Jul 30, 2023
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 commentedon Oct 28, 2023
It's a mess... taking 22GB. it keeps on increasing.... and my machine starts to shy away...
piaopiaoquan commentedon Jan 12, 2024
i am using vs code in mac, the lldb-mi is like dead frequently when debugging , and the memory it taked increaing
lucianthorr commentedon Jul 19, 2024
Still an issue here. VSCode with the CMake Tools extension. I have two lldb-mi processes running, each taking ~20GB of memory somehow.
samuelbodin commentedon Nov 1, 2024
Has there been a more recent fix for this yet? Im running into the same issue... each debug instance I start just keeps expanding in memory until crash.
shubrahgupta commentedon Nov 23, 2024
Hi, this is still an issue. It kept eating up the memory until I received warning to kill one of the processes. Checking in the Activity monitor, there were 2 processes of lldb active, which I had to force stop.
git-flyer commentedon Dec 2, 2024
And 2024/12/02 too. Using command-line debugging can temporarily avoid this problem.
Wangguoliyes commentedon Dec 3, 2024
who make the fxxking problem！
lanl2vz commentedon Dec 5, 2024
Me Seven I guess?
fhkong commentedon May 8, 2025
I met the fxxking same problem! It eats my 46GiB memory.
tanish35 commentedon May 17, 2025
met with the same problem my entire system ran out of memory
timothy020 commentedon May 29, 2025
the problem still exists. it eats 50GB momory
Carlos-EAC commentedon Sep 4, 2025
This just happened to me, two lldb-mi processes taking up 35 GB of memory (dwarfing Chrome's 1 GB, .2 GB after restarting it). They didn't close when I closed VSCode.