[Feature Request] Implement some sort of variable paging, or at least limit variable lists #889
Comments
|
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 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
changed the title
|
Thanks for the clear report and repro steps! I gave it a spin and findings:
Garbage in... garbage out. But FWIW when I try your repro, I get this: 
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. |
Added a new setting 'max_variable_children' defaulting to 200. This is pretty lame, but could help with pathological cases like #889. Better options for the future: - allow <CR> on the ... to show "everything" - implement paging properly - also make the code less inefficient.
|
I pushed a branch with a possible hack around to limit the number of children printed. Can you try it? 
|
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. |
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
The text was updated successfully, but these errors were encountered: