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. >
Modifying the the contents of a buffer doesn't impact the location list. Various other commands also load or enter a buffer that triggers a BufEnter autocommand. So this is independent of the location list functionality and is handled when entering a buffer. Modifying the location list itself from a BufEnter autocommand will impact the location list functionality. This is handled by the above mentioned patch. > > You can add safeguards against jumping beyond EOF. I'll then come > up with a slightly more complicated crash. :) > As mentioned above this is independent of the location list and is handled by the buffer management functions. > >> > 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"? > Consider for example, you have a BufReadPre autocommand that either uncompresses a file or performs a network operation to load the buffer. If these autocommands are delayed, then the buffer cannot be loaded and the location list cannot position the cursor. Note that selecting an entry from the location can trigger various autocommands depending on whether the buffer is already loaded in a window or hidden or not in memory. Also, depending on the 'switchbuf' setting, selecting an entry from the quickfix list can create a new window or a tab, jump to a tab or window. This will trigger additional autocommand events. You cannot delay autocommands in these cases (for example TabEnter/WinEnter). - Yegappan > > 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. > > /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.
