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.
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.
Therefore, I'd like to see an example of how the "current quickfix
operation"
can be broken by e.g. a WinEnter autocommand.
Best,
Christian
--
--
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.
