bug related to patch 7.3.449 (Autocommands caused command to abort)

[Alex Efros]

Hi!

I've discover this bug when trying to ':wq' in file with syntax errors using
syntastic plugin with
let g:syntastic_auto_loc_list=1
Instead of exiting from vim no matter there are syntax errors I got either
E855: Autocommands caused command to abort
or vim segfault.


To reproduce this bug it's enough to:

$ vi -u /dev/null --noplugin
:autocmd BufWinLeave * if empty(&bt) | lclose | endif
:lexpr system('echo :1:some')
:lopen
:wincmd p
:q
(location list closes; got message E855: Autocommands caused command to
abort; vim doesn't exit)
:q
(now vim exit)

Or, with tabs and segfault:

$ vi -u /dev/null --noplugin
:autocmd BufWinLeave * if empty(&bt) | lclose | endif
:tabnew
:lexpr system('echo :1:some')
:lopen
:wincmd p
:q
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault

This happens on 7.3.515. Versions before 7.3.449 behave differently
without tabs, but with tabs they all crash.


There is probably bug in that autocmd -
&bt
should be replaced with
getbufvar(0+expand('<abuf>'), '&bt')
but it fix this issue only partially, in these cases:
- :lclose in location-list window
- :lclose in file window (with opened location-list)
- :q in location-list window
but we still got error (or segfault when tabs used) in this case:
- :q in file window (with opened location-list)

In last case expand('<abuf>') return file window's number, which is
correct IMO. In this situation doing :lclose looks correct and shouldn't
result in 'Autocommands caused command to abort'.


I've implemented workaround for syntastic:
https://github.com/scrooloose/syntastic/pull/256
but it's bug in vim and should be fixed in vim.

--
WBR, Alex.

[Christian Brabandt]

Hi Alex!

On Do, 24 Mai 2012, Alex Efros wrote:

> I've discover this bug when trying to ':wq' in file with syntax errors using
> syntastic plugin with
> let g:syntastic_auto_loc_list=1
> Instead of exiting from vim no matter there are syntax errors I got either
> E855: Autocommands caused command to abort
> or vim segfault.
>
>
> To reproduce this bug it's enough to:
>
> $ vi -u /dev/null --noplugin
> :autocmd BufWinLeave * if empty(&bt) | lclose | endif
> :lexpr system('echo :1:some')
> :lopen
> :wincmd p
> :q
> (location list closes; got message E855: Autocommands caused command to
> abort; vim doesn't exit)
> :q
> (now vim exit)

I have noticed something similar in my NrrwRgn plugin.
I am not sure, this is a bug, because at the time you issue :q the
location list ist still open and in case another window is open, :q does
not exit Vim.

> Or, with tabs and segfault:
>
> $ vi -u /dev/null --noplugin
> :autocmd BufWinLeave * if empty(&bt) | lclose | endif
> :tabnew
> :lexpr system('echo :1:some')
> :lopen
> :wincmd p
> :q
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault
>
> This happens on 7.3.515. Versions before 7.3.449 behave differently
> without tabs, but with tabs they all crash.

Attached patch fixes this issue.

regards,
Christian

[James McCoy]

On Thu, May 24, 2012 at 10:14:41PM +0200, Christian Brabandt wrote:
>
> Attached patch fixes this issue.

> diff --git a/src/window.c b/src/window.c
> --- a/src/window.c
> +++ b/src/window.c
> @@ -2104,6 +2104,38 @@
> #endif
> }
>
> +int
> +close_last_window_tabpage(win, free_buf, prev_curtab)
> + win_T *win;
> + int free_buf;
> + tabpage_T *prev_curtab;
> +{
> + /*
> + * When closing the last window in a tab page first go to another tab
> + * page and then close the window and the tab page. This avoids that
> + * curwin and curtab are not invalid while we are freeing memory, they may
^^^
The "not" should be removed. You fixed this in the original version of
the comment, but not when you copied it here.

--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Christian Brabandt]

On Fri, May 25, 2012 00:20, James McCoy wrote:
> On Thu, May 24, 2012 at 10:14:41PM +0200, Christian Brabandt wrote:
>> + /*
>> + * When closing the last window in a tab page first go to another
>> tab
>> + * page and then close the window and the tab page. This avoids
>> that
>> + * curwin and curtab are not invalid while we are freeing memory,
>> they may
> ^^^
> The "not" should be removed. You fixed this in the original version of
> the comment, but not when you copied it here.

Yes, indeed. Thanks.

regards,
Christian

[Bram Moolenaar]

Great, thanks.

We can make the method static, since it's only used in window.c

--
Every engineer dreams about saving the universe and having sex with aliens.
This is much more glamorous than the real life of an engineer, which consists
of hiding from the universe and having sex without the participation of other
life forms. (Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@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 ///

[Alex Efros]

Hi!

On Thu, May 24, 2012 at 10:14:41PM +0200, Christian Brabandt wrote:

> I have noticed something similar in my NrrwRgn plugin.
> I am not sure, this is a bug, because at the time you issue :q the
> location list ist still open and in case another window is open, :q does
> not exit Vim.

I'm not really understood what you mean, sorry.

I can see reason for 'E855: Autocommands caused command to abort'
when something bad happens in a loop, for example like this:

:autocmd BufWinLeave * lclose

when it run with open location-list and result in calling :lclose
again while executing BufWinLeave as result of :lclose.

But I don't see any reason why E855 happens using this:

$ vi -u /dev/null --noplugin

:autocmd BufWinLeave * if empty(getbufvar(0+expand('<abuf>'), '&bt')) | lclose | endif

:lexpr system('echo :1:some')
:lopen
:wincmd p
:q

E855: Autocommands caused command to abort

So, is this a bug or not?

> > This happens on 7.3.515. Versions before 7.3.449 behave differently
> > without tabs, but with tabs they all crash.
>
> Attached patch fixes this issue.

Thanks! But, sorry, I just found another simple way to crash 7.3.530
without tabs:

$ vi -u /dev/null --noplugin

:autocmd BufWinLeave * if empty(getbufvar(0+expand('<abuf>'), '&bt')) | lclose | endif

:lexpr system('echo :1:some')
:lopen
:wincmd p

:bd

Vim: Caught deadly signal SEGV

Segmentation fault

:-/

--
WBR, Alex.

[Christian Brabandt]

Hi Alex!

On Fr, 25 Mai 2012, Alex Efros wrote:

> Hi!
>
> On Thu, May 24, 2012 at 10:14:41PM +0200, Christian Brabandt wrote:
> > I have noticed something similar in my NrrwRgn plugin.
> > I am not sure, this is a bug, because at the time you issue :q the
> > location list ist still open and in case another window is open, :q does
> > not exit Vim.
>
> I'm not really understood what you mean, sorry.
>
> I can see reason for 'E855: Autocommands caused command to abort'
> when something bad happens in a loop, for example like this:
>
> :autocmd BufWinLeave * lclose
>
> when it run with open location-list and result in calling :lclose
> again while executing BufWinLeave as result of :lclose.
>
> But I don't see any reason why E855 happens using this:
>
> $ vi -u /dev/null --noplugin
> :autocmd BufWinLeave * if empty(getbufvar(0+expand('<abuf>'), '&bt')) | lclose | endif
> :lexpr system('echo :1:some')
> :lopen
> :wincmd p
> :q
> E855: Autocommands caused command to abort
>
> So, is this a bug or not?

I don't think so, but Bram has the final saying. I would certainly find
it unexpected, if this would quit my vim. The error is simply telling
you, that an autocommand closed a window/buffer and that's why Vim
aborts executing the :q command.

> > > This happens on 7.3.515. Versions before 7.3.449 behave differently
> > > without tabs, but with tabs they all crash.
> >
> > Attached patch fixes this issue.
>
> Thanks! But, sorry, I just found another simple way to crash 7.3.530
> without tabs:
>
> $ vi -u /dev/null --noplugin
> :autocmd BufWinLeave * if empty(getbufvar(0+expand('<abuf>'), '&bt')) | lclose | endif
> :lexpr system('echo :1:some')
> :lopen
> :wincmd p
> :bd
> Vim: Caught deadly signal SEGV
> Segmentation fault

I'll look into it.

regards,
Christian

[Alex Efros]

Hi!

On Sat, May 26, 2012 at 07:59:41AM +0200, Christian Brabandt wrote:
> I don't think so, but Bram has the final saying. I would certainly find
> it unexpected, if this would quit my vim. The error is simply telling
> you, that an autocommand closed a window/buffer and that's why Vim
> aborts executing the :q command.

That still doesn't make sense to me. If autocommand closed some
window/buffer then current command should be aborted? Why is that?

Is there any way to work around this in BufWinLeave autocommand?

(I've work around this by moving logic to close orphan location-list
on BufEnter into that location-list, but that's ugly because it's
complicated to detect is that location-list have/have not related source
file opened, while on source file's BufWinLeave it's enough to :lclose.)

As for 'unexpected', for me it's much more unexpected to get location-list
window opened full screen after you've closed source file related to that
location-list…

--
WBR, Alex.

[Christian Brabandt]

Hi Alex!

On Sa, 26 Mai 2012, Alex Efros wrote:

> On Sat, May 26, 2012 at 07:59:41AM +0200, Christian Brabandt wrote:
> > I don't think so, but Bram has the final saying. I would certainly find
> > it unexpected, if this would quit my vim. The error is simply telling
> > you, that an autocommand closed a window/buffer and that's why Vim
> > aborts executing the :q command.
>
> That still doesn't make sense to me. If autocommand closed some
> window/buffer then current command should be aborted? Why is that?

I think this is because you could end up in a different window/buffer on
which you probably don't want the original command to work with.

> Is there any way to work around this in BufWinLeave autocommand?

Not sure, perhaps something like this:
In the buffer, to which the location list belongs, you can set a
buflocal variable of the winnr() of the location list. And on
BufWinLeave of your original buffer, you can then close the location
list that belongs to it. But I don't know if this works or if this also
aborts.


regards,
Christian

[Christian Brabandt]

Here is another patch. I made win_close() return a status, whether it
failed or not.

But although win_close() is called in many places, I made it only in 1
place at do_buffer() evaluate the return value of win_close(), to not
introduce too many other changes.

regards,
Christian
--