On 12 April 2016, Christian Brabandt <[email protected]> wrote:
> Am 2016-04-12 08:40, schrieb LCD 47:
> > On 11 April 2016, Yegappan Lakshmanan <[email protected]> wrote:
> >> Hi,
> >>
> >> On Mon, Apr 11, 2016 at 11:37 AM, LCD 47 <[email protected]> wrote:
> >> > On 11 April 2016, Christian Brabandt <[email protected]> wrote:
> >> >> Am 2016-04-11 08:20, schrieb LCD 47:
> >> >> > On 19 March 2016, Dominique Pellé <[email protected]> wrote:
> >> >> >> Hi LCD,
> >> >> >>
> >> >> >> If you can still reproduce this bug, can you check
> >> >> >> whether recent patch 7.4.1592 fixes it?
> >> >> >>
> >> >> >> patch 7.4.1592
> >> >> >> Problem: Quickfix code using memory after being freed. (Dominique
> >> >> >> Pelle)
> >> >> >> Solution: Detect that the window was closed. (Hirohito Higashi)
> >> >> >
> >> >> > (Context moved below the signature)
> >> >> >
> >> >> > Hi Dominique,
> >> >> >
> >> >> > I think I now have a better understanding of what was going
> >> >> > on in my report. Your patch fixes the crash, but there might
> >> >> > still be a deeper problem with jumping from quickfix lists.
> >> >> >
> >> >> > The crash scenario was something like this:
> >> >> >
> >> >> > (1) .ll from a loclist
> >> >> > (2) the target file for .ll had a BufEnter autocmd
> >> >> > (3) the BufEnter set a different loclist for the same window
> >> >> > (4) .ll mixed data from the old and new loclists.
> >> >> >
> >> >> > Your patch adds a safeguard against the loclist going away
> >> >> > from under .ll's feet, but the fact that an autocmd can happen in
> >> >> > the middle of the operation is still a bug, I think.
> >> >>
> >> >> Is there an easy way to reproduce the issue? Perhaps, cloning as
> >> >> github repository with mandatory setup files?
> >> >
> >> > You don't understand, there is nothing to reporduce (not yet
> >> > anyway). The issue I reported way back was fixed by patch 1592, and
> >> > by a patch to syntastic. However, I claim that the bigger picture
> >> > of quickfix is _still_ wrong.
> >> >
> >> > Namely, autocmds can occur in the middle of quickfix commands.
> >> > I don't have any use case to show what can break that way, but it's
> >> > surely obvious that this is a bad idea?
> >> >
> >>
> >> The above mentioned patch checks whether the current quickfix/location
> >> list entry is still valid after opening a buffer (assuming this event
> >> triggered an autocmd that changed the quickfix/location list). If the
> >> entry is no longer valid, then the operation is aborted.
> >
> > Umm, this is what I said above.
> >
> >> This should gracefully handle this condition.
> >
> > Sorry, but no. The autocmd can mess things up beyond repair
> > without
> > touching touching the loclist. Example:
> >
> > (1) start jumping to line 500 in exmple.txt
> > (2) example.txt has a BufEnter that deletes lines below 251
> > (3) segfault.
>
> does it? I think you'll get a bunch of ml_get errors, and if you've
> finally hit-enter'ed away all messages, I think Vim will continue to
> work fine. Depending on how many error messages you got, this can be
> annoying however.
The point is, an autocmd can mess things up by changing the context
in a way the current command doesn't expect.
> > You can add safeguards against jumping beyond EOF. I'll then
> > come up with a slightly more complicated crash. :)
> >
> >> > Shouldn't autocmds be delayed until quickfix commands are
> >> > finished?
> >> >
> >>
> >> No. Jumping to an entry in the location/quickfix list may trigger
> >> buffer, window and tab enter/leave autocmds. Delaying these autocmd
> >> events will break functionality that depends on these events.
> >
> > Can you please give an example when setting the cursor before an
> > autocmd would "break functionality that depends on these events"?
> > As far as I can tell, delaying the autocmd until the current
> > operation is finished would enable functionality (such as the
> > scenario in my initial report), rather than break functionality.
>
> I think we are all aware, that doing stupid things in an autocommand
> can break Vim and has in the past. (And we have in the past fixed too
> many bugs with autocommands changing something behind our back).
>
> I am not sure, however that defering autocommands is the right
> solution.
Why not? What does running an autocmd in the middle of a .ll
command achieve? How is that better than postponing it until .ll is
done? The .ll sets a new buffer context, why would it be better to keep
running autocmds in the context of the _old_ buffer?
> Therefore, I'd like to see an example of how the "current quickfix
> operation" can be broken by e.g. a WinEnter autocommand.
Without looking at the code, I'm not sure quickfix operations can
trigger WinEnter. Do try BufEnter instead, it already can do as much
damage as any other autocmd.
/lcd
--
--
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.
