2015-04-14 18:43 GMT+03:00 Thiago Padilha <[email protected]>:
>>  It's easy to accidentally make a Vim script that consumes all
> memory.
>
> If you see this often then you must be running Vim on a machine with
> an extremely low amount of memory. This is not the case for most users
> though, in the few years using Vim I never experienced this and I use
> some pretty heavy plugins. Even if OOM was common due to bugs in
> vimscript, it's not like the user will try to recover the current Vim
> instance without exiting. The common course of action would be to exit
> and remove the buggy vimscript program. Add this to the fact that not
> handling OOM simplifies code and you will see that it's not so weird
> that Neovim opted for this path.
>
>> Though I would better see NeoVim developers to add OOM testing rather
> then make the app crash, but this would add too much overhead for
> little gain because OOM is rare.
>
> Testing OOM should be easier now that Neovim abstracts all memory
> management functions into memory.c(for jemalloc integration). With
> some changes we could add a hook that simulates out of memory. But as
> you said, OOM is rare enough for this to have an extremely low
> priority.

Top problem with OOM testing is not hooking malloc: there are 100500
solutions for this. And not pretending that you have only N KiB of
memory left: if your program uses only malloc this is trivial once you
hooked it.

Top problem is making OOM error run *exactly* when needed. Given
`xmalloc` crashing NeoVim on hard OOM this is one function to test.
Given `malloc` returning NULL in Vim this means that you must pretend
there is OOM at least once per each code line that uses memory
allocation (note: some of code lines are multiplied by possible Vim
states which make OOM handling different). And, to make matters worse,
you usually run tests without gdb or valgrind meaning that you don’t
know context where `malloc` was called.

>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui