New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Neo)Vim hangs with freeing a lot of objects #1687

Closed
Shougo opened this Issue Dec 16, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@Shougo
Contributor

Shougo commented Dec 16, 2014

https://groups.google.com/forum/#!searchin/vim_dev/GC/vim_dev/DBYOdHQWvqY/1WH04_dwETIJ

I think this patch is important for neovim and Vim.
But it is not included yet.

Do you think about the problem?

Note: This problem maybe reproduced if you use unite.vim. Because, unite.vim uses a lot of memories.

@justinmk justinmk added the bug-vim label Dec 16, 2014

@aktau

This comment has been minimized.

Show comment
Hide comment
@aktau

aktau Dec 16, 2014

Member

It is most definitely something we should look into as this could be a very quick and very good win. Our more developed memory leak checking infrastructure might allow us to debug any problems that surface. Still, I've been thinking for a while that there should be functional tests that put the scripting engine through its paces in more detail by loading some complicated user contributed scripts and exercising their functionalities. If we do that, we can be even more confident that no leaks are introduced (though we can't be sure). No substitute for a well-reasoned approach, but I'm not sure we have someone on the team that knows about all the tentacles of the scripting engine and the gc.

Member

aktau commented Dec 16, 2014

It is most definitely something we should look into as this could be a very quick and very good win. Our more developed memory leak checking infrastructure might allow us to debug any problems that surface. Still, I've been thinking for a while that there should be functional tests that put the scripting engine through its paces in more detail by loading some complicated user contributed scripts and exercising their functionalities. If we do that, we can be even more confident that no leaks are introduced (though we can't be sure). No substitute for a well-reasoned approach, but I'm not sure we have someone on the team that knows about all the tentacles of the scripting engine and the gc.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 16, 2014

Member

by loading some complicated user contributed scripts

Same here. We can easily start running vader tests against some of these plugins:

https://github.com/junegunn/vader.vim/wiki/Projects-using-Vader

Sample test output: https://travis-ci.org/junegunn/vim-easy-align

vader.vim is a pure-vimscript test framework, and feels similar to our own functional tests. It would be a relatively easy way to get more test coverage.

Member

justinmk commented Dec 16, 2014

by loading some complicated user contributed scripts

Same here. We can easily start running vader tests against some of these plugins:

https://github.com/junegunn/vader.vim/wiki/Projects-using-Vader

Sample test output: https://travis-ci.org/junegunn/vim-easy-align

vader.vim is a pure-vimscript test framework, and feels similar to our own functional tests. It would be a relatively easy way to get more test coverage.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 19, 2015

Is this still an issue after #1761?

ghost commented Jan 19, 2015

Is this still an issue after #1761?

@justinmk justinmk closed this Jan 19, 2015

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jan 19, 2015

Member

No, thanks @Pyrohh

Member

justinmk commented Jan 19, 2015

No, thanks @Pyrohh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment