Open kentkr opened 1 month ago
kentkr
commented
3 weeks ago So this actually does replicate in vim.
Luckily on further inspection just waiting +30s to let vimspector do its thing allows it to function. The problem must've been running things like :VimspectorRestart in the middle of a process.
This doesn't occur in lldb on its own, so vimspector isn't working as expected. I'm happy to help profile and contribute if needed.
puremourning
commented
2 weeks ago Thanks for the clear report and repro steps!
I gave it a spin and findings:
1) this is entirely due to the debug adapter returning a very large number of child items. Vimspector doesn't implement variable paging, which I think exists in the protocol, but I suppose it could at a cost of Ben Hours. 2) what did you expect to happen in expanding an uninitialised map? the map is uninitialised random data. there's no way for the debugger (lldb) to know that, so it reads a random value for the size of the map then tries to walk infinite memory, producing garbage.
Garbage in... garbage out.
But FWIW when I try your repro, I get this:
*- m: size=7544
*+ [0]: {first:'\0', second:0}so my random value was 7544
opening this took ~ 10ms which is of course forever in computing terms, but not so bad in human terms. I've no doubt if the random number was 2^63 it would take a long time indeed.
I admit the code that draws these "trees" is awful and extremely inefficient python slop, but short of implementing paging (which is very expensive in Ben Time) for a fairly rare issue, I'm not sure it's worth it.
I've converted this to a feature request for restricting the number of variables requested or implementing paging.
puremourning
commented
2 weeks ago I pushed a branch with a possible hack around to limit the number of children printed.
Can you try it?
https://github.com/puremourning/vimspector/pull/892
kentkr
commented
2 weeks ago
- what did you expect ...
Nothing! I'm new to c++ lol.
I agree with your assessment, this is rare (also avoidable) and ben time is very rare commodity. After learning more about c++ I see why this would happen. Is there a reason your map would be 7544 while mine is 2^63?
I tried #892, it was slow but worked on the first pass. After opening the map again it broke with similar errors.
If this plagues me more and I have free time I may reach out to contribute. Thanks for taking a look.
puremourning
commented
2 weeks ago Is there a reason your map would be 7544 while mine is 2^63?
no it is random. Look up uninitialised variables in your c++ text book.
Description
When accessing a declared, but uninstantiated, map in the Variables view there is a memory leak. Python, neovim, and codelldb begin to use 2+gb of RAM each. Vimspector becomes unresponsive and neovim must be force quit.
Is it reproducible in vim?
Only broken in Neovim
Works with clean config?
Yes
Sample project works?
Reproducible with sample project
Minimal Reproduction
List of steps to reproduce:
eg.cppCMakeLists.txt.vimspector.jsoncmake .thencmake --build .eg.cpp:call vimspector#SetLineBreakpoint('eg.cpp', 4):call vimspector#Launch()vimspector.VariablesScope: localtry to to open up themvariable by hovering over it and hitting enter/returnExpected Behaviour
Accessing the variable before it is instantiated should not cause a memory leak.
Or at least if it does the debugger should be able to reset. It currently goes unresponsive.
Actual Behaviour
The debugger (vimspector commands) are no longer responsive, throwing a python eval error. Neovim stays active (unless in tmux which hangs forever).
The processes for neovim, python, and codelldb begin to use excessive amounts of memory. The only way out of this is to force quite the neovim process that originally launched the vimspector session.
If that process is not stopped then any new session that's created will experience the same issue.
Additional information
I'm a c++ novice so wouldn't be surprised if I'm making a mistake somewhere.
I'm happy to contribute if needed!
Installation Type
Other (specify in notes)
Vimspector version
vim-plug. Sorry I'm not sure what you need from git rev-parse HEAD
Debug Info
Operating System
Darwin Kyles-MBP-2.attlocal.net 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct 9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64
Declaration