Yegappan wrote:
> > > On Sat, Oct 13, 2018 at 7:58 AM Yegappan Lakshmanan <yegapp...@gmail.com> > > > w= > > > rote: > > > > > > > > On Sat, Oct 13, 2018 at 1:11 AM Dominique Pell=C3=A9 > > > > <vim-dev-git...@256bit.org> wrote: > > > > > > > > > > Here is another use of free memory also found by afl-fuzz > > > > > which may be related to the previous one despite having > > > > > a different stack: > > > > > > > > > > > > > Thanks for reporting these. I am able to reproduce the problem. > > > > I am trying to address this and will send out a patch later. > > > > > > > > > > The attached patch fixes these crashes. I am still working on cleaning up > > > the changes. So it is not yet ready to be included. > > > > > > Freeing up a quickfix/location list/stack or freeing up a buffer or > > > closing= > > > a > > > window or tab page from an autocmd is unexpected and causes a lot > > > of issues. Checking for these conditions in the code all over the place > > > creates a lot of clutter and inefficiencies. I am not sure how to cleanly > > > handle these conditions without adding a lot of checks. We need to add > > > checks after every function call that can trigger an autocmd. > > > > Some strategies are: > > - Forbid the autocommand to make some changes. E.g. we have the b_locked > > flag. > > - Don't use local pointers, use an index or unique ID to refer to > > items (e.g. use buffer number instead of buffer pointer. > > - Do use a pointer, but have a way to check if it's still valid. E.g. > > win_valid(). > > > > Thanks for the suggestion. > > The code already uses the quickfix list identifier to check whether a > list is still present or not after an autocmd. This is simpler for the > quickfix stack as the stack will never get freed. But the location list > stack itself can get freed by setloclist(). > > To check whether the location list stack is still present or not, we > need to iterate through all the windows in all the tab pages looking for > a window with the location list stack. Even if I use the window > identifier, we still have to iterate through all the windows. The > location list stack can be referenced either by a file window or a > location list window. > > This will cause a performance problem, as we need to do this a few times > in the process of adding an entry to the quickfix/location list. > > Sometime ago I was working on adding a reference count to the quickfix > stack/list. But it lead to a lot of code changes and still didn't cleanly > solve > the problem. Can you (easily) mark the code that is manipulating the location list? Something like 'quickfix_busy' that is incremented before doing some work and decremented when done? Then you could check for that flag and when it's > 0 then not delete the location list stack, but put it in a "to be deleted" list. Then when decrementing 'quickfix_busy' to zero those can be deleted. This is an efficient method, since the extra work is mostly done only when something unusual is happening. Something similar is happening for user functions, esp. self-deleting functions. -- hundred-and-one symptoms of being an internet addict: 213. Your kids start referring to you as "that guy in front of the monitor." /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
