Loading ...
Sorry, an error occurred while loading the content.

vim segfault on :cclose in BufUnload (with python?)

Expand Messages
  • Sean Reifschneider
    Since vim 7.3 patch 429 (on Ubuntu Precise/12.04), it looks like there s a segfault issue when doing cclose on BufUnload in a python function. In
    Message 1 of 4 , Dec 17, 2012
    • 0 Attachment
      Since vim 7.3 patch 429 (on Ubuntu Precise/12.04), it looks like there's a segfault issue when doing "cclose" on BufUnload in a python function. In particular, it happens on 7.3 patch 547 (Ubuntu Quantal/12.10), and is also happening on 7.3 patch 762 (latest tag in Mercurial checkout).

      Here's how I'm able to reproduce it:

      Create a file /tmp/blowup.vim:

      pyfile /tmp/blowup.py
      botright 3copen
      autocmd BufUnload * python leaving_buffer()

      Then create a file /tmp/blowup.py:

      import vim
      def leaving_buffer():
      vim.command('cclose')
      vim.command('quit')

      Now run "vim -u tmp/blowup.vim /tmp/foo" (in my case, /tmp/foo does not exist). Do ":q" in vim, and it will segfault:

      Vim: Caught deadly signal SEGV
      zsh: segmentation fault (core dumped) vim -u /tmp/blowup.vim /tmp/foo

      I compiled it using the Ubuntu packaging for Precise, against the mercurial checkout for 762. Here is the "--version" output:

      guin:vim-quantal$ vim --version
      VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Dec 17 2012 12:54:39)
      Included patches: 1-762
      Modified by XXX
      Compiled by XXX
      Huge version with GTK2 GUI. Features included (+) or not (-):
      +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
      +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
      +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
      +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
      +file_in_path +find_in_path +float +folding -footer +fork() +gettext
      -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
      +linebreak +lispindent +listcmds +localmap +lua +menu +mksession +modify_fname
      +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
      +mouse_sgr -mouse_sysmouse +mouse_urxvt +mouse_xterm +multi_byte +multi_lang
      -mzscheme +netbeans_intg +path_extra +perl +persistent_undo +postscript
      +printer +profile +python -python3 +quickfix +reltime +rightleft +ruby
      +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop
      +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse
      +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual
      +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup
      +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save
      system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
      system gvimrc file: "$VIM/gvimrc"
      user gvimrc file: "$HOME/.gvimrc"
      system menu file: "$VIMRUNTIME/menu.vim"
      fall-back for $VIM: "/usr/share/vim"
      Compilation: gcc-4.6 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/include/tcl8.5 -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
      Linking: gcc-4.6 -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.1 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.14/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.5 -ldl -lpthread -lieee -lm -lruby-1.9.1 -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib

      Thanks,
      Sean

      --
      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
    • Christian Brabandt
      Hi Sean! ... This is an issue, that seems to come up in one or another form every couple of months here. The root cause is always autocommands closing all
      Message 2 of 4 , Dec 17, 2012
      • 0 Attachment
        Hi Sean!

        On Mo, 17 Dez 2012, Sean Reifschneider wrote:

        > Since vim 7.3 patch 429 (on Ubuntu Precise/12.04), it looks like there's a segfault issue when doing "cclose" on BufUnload in a python function. In particular, it happens on 7.3 patch 547 (Ubuntu Quantal/12.10), and is also happening on 7.3 patch 762 (latest tag in Mercurial checkout).
        >
        > Here's how I'm able to reproduce it:
        >
        > Create a file /tmp/blowup.vim:
        >
        > pyfile /tmp/blowup.py
        > botright 3copen
        > autocmd BufUnload * python leaving_buffer()
        >
        > Then create a file /tmp/blowup.py:
        >
        > import vim
        > def leaving_buffer():
        > vim.command('cclose')
        > vim.command('quit')
        >
        > Now run "vim -u tmp/blowup.vim /tmp/foo" (in my case, /tmp/foo does not exist). Do ":q" in vim, and it will segfault:
        >
        > Vim: Caught deadly signal SEGV
        > zsh: segmentation fault (core dumped) vim -u /tmp/blowup.vim /tmp/foo
        >

        This is an issue, that seems to come up in one or another form every
        couple of months here. The root cause is always autocommands closing all
        windows and buffers, which Vim does not expect and so it crashes sooner
        or later. Here is a patch, trying to prevent this another time:

        diff --git a/src/main.c b/src/main.c
        --- a/src/main.c
        +++ b/src/main.c
        @@ -1376,6 +1376,8 @@
        for (wp = (tp == curtab)
        ? firstwin : tp->tp_firstwin; wp != NULL; wp = wp->w_next)
        {
        + if (wp->w_buffer == NULL)
        + continue;
        buf = wp->w_buffer;
        if (buf->b_changedtick != -1)
        {
        diff --git a/src/window.c b/src/window.c
        --- a/src/window.c
        +++ b/src/window.c
        @@ -2276,9 +2276,13 @@
        #endif
        }

        + if ( only_one_window() && (!win_valid(win) || last_window() || curtab != prev_curtab
        + || close_last_window_tabpage(win, free_buf, prev_curtab)))
        + /* autocommands have close all windows, quit now */
        + getout(0);
        /* Autocommands may have closed the window already, or closed the only
        * other window or moved to another tab page. */
        - if (!win_valid(win) || last_window() || curtab != prev_curtab
        + else if (!win_valid(win) || last_window() || curtab != prev_curtab
        || close_last_window_tabpage(win, free_buf, prev_curtab))
        return;

        @@ -6281,7 +6285,7 @@
        if (first_tabpage->tp_next != NULL)
        return FALSE;

        - for (wp = firstwin; wp != NULL; wp = wp->w_next)
        + for (wp = firstwin; wp != NULL && wp->w_buffer != NULL; wp = wp->w_next)
        if ((!((wp->w_buffer->b_help && !curbuf->b_help)
        # ifdef FEAT_QUICKFIX
        || wp->w_p_pvw


        This does quit Vim, in case an autocommand closes all other
        windows/buffers while Vim is processing the win_close() function.

        regards,
        Christian
        --
        Wer in einem gewissen Alter nicht merkt, daß er hauptsächlich
        von Idioten umgeben ist, merkt es aus einem gewissen Grunde nicht.
        -- Curt Goetz

        --
        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
      • Bram Moolenaar
        ... Thanks Christian, added to the todo list. Note that I am travelling, expect some delay. ... What if there are unsaved changes? -- hundred-and-one symptoms
        Message 3 of 4 , Dec 18, 2012
        • 0 Attachment
          Christian Brabandt wrote:

          > On Mo, 17 Dez 2012, Sean Reifschneider wrote:
          >
          > > Since vim 7.3 patch 429 (on Ubuntu Precise/12.04), it looks like there's a segfault issue when doing "cclose" on BufUnload in a python function. In particular, it happens on 7.3 patch 547 (Ubuntu Quantal/12.10), and is also happening on 7.3 patch 762 (latest tag in Mercurial checkout).
          > >
          > > Here's how I'm able to reproduce it:
          > >
          > > Create a file /tmp/blowup.vim:
          > >
          > > pyfile /tmp/blowup.py
          > > botright 3copen
          > > autocmd BufUnload * python leaving_buffer()
          > >
          > > Then create a file /tmp/blowup.py:
          > >
          > > import vim
          > > def leaving_buffer():
          > > vim.command('cclose')
          > > vim.command('quit')
          > >
          > > Now run "vim -u tmp/blowup.vim /tmp/foo" (in my case, /tmp/foo does not exist). Do ":q" in vim, and it will segfault:
          > >
          > > Vim: Caught deadly signal SEGV
          > > zsh: segmentation fault (core dumped) vim -u /tmp/blowup.vim /tmp/foo
          > >
          >
          > This is an issue, that seems to come up in one or another form every
          > couple of months here. The root cause is always autocommands closing all
          > windows and buffers, which Vim does not expect and so it crashes sooner
          > or later. Here is a patch, trying to prevent this another time:

          Thanks Christian, added to the todo list.
          Note that I am travelling, expect some delay.


          > This does quit Vim, in case an autocommand closes all other
          > windows/buffers while Vim is processing the win_close() function.

          What if there are unsaved changes?


          --
          hundred-and-one symptoms of being an internet addict:
          175. You send yourself e-mail before you go to bed to remind you
          what to do when you wake up.

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

          --
          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
        • Christian Brabandt
          Hi Bram! ... Here is a small updated patch. unsaved changes shouldn t be a problem in this case, since we are explicitly checking that the buffer is null.
          Message 4 of 4 , Dec 18, 2012
          • 0 Attachment
            Hi Bram!

            On Di, 18 Dez 2012, Bram Moolenaar wrote:

            >
            > Christian Brabandt wrote:
            >
            > > On Mo, 17 Dez 2012, Sean Reifschneider wrote:
            > >
            > > > Since vim 7.3 patch 429 (on Ubuntu Precise/12.04), it looks like there's a segfault issue when doing "cclose" on BufUnload in a python function. In particular, it happens on 7.3 patch 547 (Ubuntu Quantal/12.10), and is also happening on 7.3 patch 762 (latest tag in Mercurial checkout).
            > > >
            > > > Here's how I'm able to reproduce it:
            > > >
            > > > Create a file /tmp/blowup.vim:
            > > >
            > > > pyfile /tmp/blowup.py
            > > > botright 3copen
            > > > autocmd BufUnload * python leaving_buffer()
            > > >
            > > > Then create a file /tmp/blowup.py:
            > > >
            > > > import vim
            > > > def leaving_buffer():
            > > > vim.command('cclose')
            > > > vim.command('quit')
            > > >
            > > > Now run "vim -u tmp/blowup.vim /tmp/foo" (in my case, /tmp/foo does not exist). Do ":q" in vim, and it will segfault:
            > > >
            > > > Vim: Caught deadly signal SEGV
            > > > zsh: segmentation fault (core dumped) vim -u /tmp/blowup.vim /tmp/foo
            > > >
            > >
            > > This is an issue, that seems to come up in one or another form every
            > > couple of months here. The root cause is always autocommands closing all
            > > windows and buffers, which Vim does not expect and so it crashes sooner
            > > or later. Here is a patch, trying to prevent this another time:
            >
            > Thanks Christian, added to the todo list.
            > Note that I am travelling, expect some delay.
            >
            >
            > > This does quit Vim, in case an autocommand closes all other
            > > windows/buffers while Vim is processing the win_close() function.
            >
            > What if there are unsaved changes?

            Here is a small updated patch. unsaved changes shouldn't be a problem in
            this case, since we are explicitly checking that the buffer is null.


            regards,
            Christian
            --
            Man ist nur vielseitig, wenn man zum Höchsten strebt, weil man
            muss (im Ernst), und zum Geringern herabsteigt, wenn man will (zum
            Spaß).
            -- Goethe, Maximen und Reflektionen, Nr. 1157

            --
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.