Hi, >> >> >> > 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. >
A quickfix operation can trigger a WinEnter/TabEnter autocommand event depending on the 'switchbuf' setting. - Yegappan -- -- 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.
