vim segfaults on write

[exhuma]

Edit: Also happens on simple :w

Two colleagues of mine have told me that thei vim segfaults regularly. But only on save/quit (:wq). I tried to find out why, but could not find the culprit. We all have pretty much the same plugins installed. In any case, we have rules out plugins for a while. After all I have all those installed as well, and have no seg-faults.

Recently I upgraded python-mode. Since then I get the same problem.

I cannot tell you much more other than it seems to happen only on write+quit.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[JamesWiley]

This sounds like a duplicate of Issue #349

[exhuma]

Not so sure. It seems that #349 will still let you stay in vim. In our case, vim completely crashes out. All buffers, history and everything lost :'(

Also #349 does not mention a segfault.

[exhuma]

Additional info: I am on e6a8d55 (develop branch).

[exhuma]

After an additional test I can confirm this! A colleague had not yet python-mode installed (ever). Took him as guinea pig and added python-mode to his bundles. That was about 3 hours ago. His first ever segfault happened just now. So it is indeed caused by python-mode!

[exhuma]

Just now, it also crashed on a simple :w without "quit".

Is there any way I can find more information on the SEGV? It does not give a traceback of any kind, and I'm no C wizard, so I have no experience with gdb. Is there a way to do post-mortem debugging? I could add more information...

[jinhakang]

I am having the same problem. I changed using master branch instead of developer branch and the problem is gone. The two branches show different actions when I do ':wq'. While the develop branch shuts down all windows and goes back to shell, the master version closes only the editing window and the lint window leaves alive, so I needed to do ':q' once again but it works without error.

[netzmb]

Same problem. Vim crashes if pylint return a lot of mistakes and user try to save changed file

[exhuma]

@jinhakang Interesting... I am also working on a "develop" branch. I have not paid attention to this fact. I cannot say if the problem exists on both "develop" and "master". But I will try to keep an eye out for this. The problem still persists for me and seems to happen very randomly.

[FunTimeCoding]

I have this problem too, I think.

[FunTimeCoding]

on the other hand. it works fine with the native osx vim, but brew vim crashes. will investigate further.

[FunTimeCoding]

my problem was having a .ropeproject in my home directory. I fixed it by deleting that.

[exhuma]

Just verified. I have no .ropeproject in my $HOME :(

[FunTimeCoding]

I came across this setting that helped for someone else on my research: let g:pymode_trim_whitespaces = 0

did you try that yet?

[exhuma]

Not yet. I will do!

For me it's very difficult to say, because it only happens very randomly. There can be weeks without problem, but then it can easily happen 5 times as day at other times :(

I assume it's linked to how busy the machine is, but it's very hard to tell.

I will try disabling the setting and see if I can get 1-2 months without problem.

[exhuma]

Didn't work. Even with let g:pymode_trim_whitespaces = 0 in my vimrc, it segfaulted on me just now again :(

[exhuma]

I can verify that the whitespace does not fix the issue. Has crashed on me again at least a good ten times since the last post. :(

[exhuma]

I left python-mode for a while, and the problem disappeared. Came back because indentation and folding in python-mode just rock way too much ;)

Alas, the segfaults have come back.

Right now it happened when switching buffers (using :blast). This is something I rarely ever do, so it never happened earlier.

[krader1961]

First thing to note is that a SIGSEGV failure means the program accessed an illegal memory address. It means there is a bug in the core python implementation or a dynamically loaded library. Such failures can be triggered by python code (e.g., the python-mode code) doing something unexpected but the bug itself lies elsewhere.

What operating system are you running? If it's Mac OS X you should have gotten a "Problem Report" dialog that shows relevant information like the stack of the process. If it's some other flavor of UNIX you may need to run "ulimit -c unlimited" to allow for a core dump to be saved. Then the next time vim dies run

gdb /path/to/vim /path/to/core
bt

The resulting backtrace might provide enough clues to identify or at least narrow down the cause of the failure. If not then things get more difficult since analyzing a core dump is something of an art form that can't be done via simple recipes. It's often simpler to eliminate variables (e.g., disable python-mode features one at a time) until the problem goes away then infer possible causes from that information.

[exhuma]

Thanks @krader1961 . I will try this on the next occasion. Will the path/to/core be referenced in the core dump?

[krader1961]

The /path/to/core is the filename of the core dump. So if you have the core dump in hand you should know the path. Exactly where the core is written depends on your OS. On OS X it is the directory /cores (see the output of sysctl -a | grep core). It's more typically the current working directory of the process. If your OS has a sysctl command run "sysctl -a" and see what the kernel.core* vars say.

[exhuma]

Hmmm... I don't see a path in sysctl -a. So I'll assume it's the cwd as you say. In any case. I temporarily disabled the coredump ulimit via my shell-rc. So I should get something more sensible next time it happens. Now I just have to wait until it crashes again ;)

[exhuma]

Just had another segfault, but I find the gdb output unexpectedly small:

 GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/vim...(no debugging symbols found)...done.
[New LWP 19171]
[New LWP 19172]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `vim pynet/cli.py'.
Program terminated with signal 11, Segmentation fault.
#0  0x081f66d9 in getout ()
(gdb) bt
#0  0x081f66d9 in getout ()
#1  0x08123398 in preserve_exit ()
#2  <signal handler called>
#3  0x0817f97a in update_screen ()
#4  0x081f7124 in main_loop ()
#5  0x08075184 in main ()

Not sure if the following has anything to do with this:

[...]
warning: Can't read pathname for load map: Input/output error.
[...]

[exhuma]

... just 5 minutes later, next segfault. With an identical backtrace.

[krader1961]

You can ignore the "Can't read pathname" warning. The backtrace is surprising but reasonable. I say surprising because I was sort of expecting the fault in a different routine such as one related to the embedded python interpreter. There are only a couple of reasons the update_screen function would SIGSEGV. The first is that the current window variable (curwin) was a bogus address. Not very likely. The second that one of the pointers in the window linked list was bogus (or equivalently the linked list was damaged). The third, and I think most likely, is that the buffer address associated with one of the windows was bogus. My SWAG is that the lint checkers are somehow creating a window to display lint results but not associate a buffer with the window.

I find that with these types of problems it greatly helps the debugging if you can find way to reproduce the failure on demand. Or at least frequently enough to make it feasible to explore various hypotheses.

Try disabling the lint checkers at file write time: let g:pymode_lint_on_write=0. Also, see if you can reproduce the failure running the linters by hand: :PymodeLint<cr>. Of course the problem may involve a different pymode subsystem. For example, you might try setting let g:pymode_rope_regenerate_on_write=0 to see if that makes the problem go away. But I think the odds are good that it involves the linters.

[exhuma]

I have been trying many times to find a way to reproduce it. I haven't been able to do so yet. Even if I have a file open which causes the crash an re-open/close it multiple times, it refuses to crash in a predictable manner :( I will continue to try. I will also tell my co-workers to do so (we all suffer from the same issue).

On a side-note, we mostly work on a multi-user system. So we all use the same vim binary and system libraries. The thing which may vary is everything user-related (plugins, plugin-versions and vim config).

I have the sneaking impression that it happens most predictably on :wq. But I vaguely remember that it also happened once on a simple :w. But my gut tells me to first focus on the :wq.

As pymode tries to run the linters in the background and display the results once they are finished the target window/buffer may already be gone as :wq closes the window. Even if other tabs are still open. But that's just a wild educated guess...

[exhuma]

I seem to have something which crashes all the time. First, my vim version info:

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May  4 2012 04:10:09)
Included patches: 1-429
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version with GTK2-GNOME 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_sysmouse +mouse_xterm +mouse_urxvt +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 -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   -pthread -DORBIT2=1 -D_REENTRANT -I/usr/include/libgnomeui-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1 -I/usr/include/gtk-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/i386-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/cairo -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/libart-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0     -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -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   -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     -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -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 -lgconf-2 -lgthread-2.0 -lgmodule-2.0 -lrt -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 -lruby1.8 -lpthread -lrt -ldl -lcrypt -lm  -L/usr/lib   

And then here's a simple bash script which creates an environment which, without fail always crashes (at least so far...). Just run the script from within an empty folder. Alternatively, read it and execute the steps manually ;)

Note: I have added the g:pymode_lint_unmodified setting so the linters will actually run on :wq. It has nothing to do with the crash itself. In general, the crash usually happens (in my opinion) when pymode tries to access a buffer/window which is no longer there (because you've told vim to quit).

#!/bin/bash
git clone http://github.com/klen/python-mode.git pmvim

# make sure we have the same revision as I tested with
(cd pmvim && git co 2d325c5)

echo Creating example vimrc...
cat > vimrc <<EOF
set nocompatible
set rtp=pmvim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim73,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after
filetype plugin indent on
let g:pymode_lint_unmodified = 1

" vim: set shiftwidth=4 tabstop=4 expandtab:
" vim: set foldmethod=marker foldmarker={{{,}}} foldenable foldlevel=0:
EOF


echo Creating python script which causes the crash...
cat > test.py <<EOF
def hello():
    print "world"




def foo () :
    return 1*1*1*1
EOF


echo Creating a script to simplify the test run
cat > run <<EOF
#!/bin/bash
vim -u vimrc test.py
EOF
chmod +x run


echo Now simply execute "./run" and quit vim using ":wq"

[krader1961]

Excellent. I'll try to reproduce in a few hours (it's 0700 where I'm at and I'm about to walk my dogs). I never use :wq which may be why I haven't seen the problem.

[krader1961]

Sorry but I can't reproduce this on either Linux (Ubuntu) or Mac OS X 10.9.4 using Vim 7.4 (via Homebrew on OS X). Using the native /usr/bin/vim (Vim 7.3) on OS X I also could not reproduce the problem but did see interesting, unexpected, behavior. Specifically, this

[Pymode] Found errors and warnings: 6

was written at the bottom of the screen, no lint message buffer was displayed, and Vim was left in a weird state. Typing 'j' did not move the cursor down one line. Instead it echoed a literal 'j' to the screen on the first line of the window (where the cursor was). Typing ":quit" exited Vim. I suspect that behavior is a different manifestation of the problem you're seeing. Can you try to reproduce the problem using Vim 7.4?

[exhuma]

I'll give it a go. In any case, the machine on which this is running, is scheduled to be upgraded in the next months, so it should automatically get 7.4. We'll see how this goes.

I find it useful to investigate nonetheless, as other people seem to run into this as well.

Thanks a lot for the effort in any case :)

[exhuma]

Hmmm... I just have vim re-compiled myself (7.3) and don't seem to have the problem anymore. I'm currently on a holiday, but will try next week to do the same at work.

[exhuma]

I seem to able to reproduce the error on each machine where the official vim 7.3 package is installed (All kubuntu by the way). Since this error is really sporadic, and really hard to reproduce in a controlled manner, I have tried to install vim 7.4 and can say that I no longer have this issue. Same as 7.3 in my previous comment.

So, normally I would consider it to be a problem with the vim package in *buntu.

However, a co-worker is still using the official kubuntu package (I consider him my one-man control-group 😆 ) and he himself has no issues any longer. We all work mostly on one shared development box, so the only thing different between him and me is the installed vim version. I installed 7.4 with a separate prefix, so they don't interfere with each other. I also did not need to install any other system dependencies which could have caused the official package to "suddenly work".

I would tend to say that, if anyone else can confirm this, we could consider this issue closed? I am yet a bit reluctant, as neither my personal guinea pig nor me had any issue for the same amount of time. Might still be pure coincidence again... 😢

[pavlov99]

@exhuma I confirm that I have the same issue. It is master branch of python-mode and vim compiled from latest source code.

[pavlov99]

Seems, I did not have enough memory in my virtual machine. Vim took 600Mb.

[exhuma]

Interesting. I just checked our graphs, and saw that our sysadmin added some memory around the time I switched to vim 7.4. Apparently, there have been no problems with 7.3 as well now for some time. If this really turns out to be the solution then I feel stupid.

However, I wonder why I got a segfault instead of an OOM error. Are segfaults not related to errors where a process tries to access memory it does not have access to? Could it be that the OS interfered with the process somehow?

@krader1961 do you have any insight on this? That is a bit out of my area of expertise. You seem to have more experience in that area ;)

[krader1961]

@exhuma As you noted a SIGSEGV failure means the process attempted an invalid memory access. This is usually because the address is invalid (e.g., zero or NULL) but can also occur if, for example, an attempt is made to write to a read-only page. OOM failures will frequently result in SIGSEGV failures because way too much code simply assumes that a malloc() call (or C++ "new", etc.) will always succeed and thus not confirm that the allocation succeeded. When it subsequently tries to use the invalid pointer you get a SIGSEGV. I personally consider failing to check for memory allocation failures and issuing an appropriate diagnostic before gracefully exiting a bug. But the practice is so prevalent that you might as well put on your Don Quixote costume and tilt at windmills.

P.S., Note that a kernel OOM is related to but not the same thing as a process OOM. Either can occur without the other occurring at the same time.

[exhuma]

That makes perfect sense. Thank you!

I was planning to make a VM with little to no memory to see if this will reproduce the error, but I got held up. If that's the case, I would be okay to mark this as a "won't fix" as it may not be the fault of python-mode at all.

I will keep you posted.

[exhuma]

It does not seem to be a memory issue.

The problem has suddenly appeared again on both the box where that one team member still works with vim 7.3 and on my personal laptop. Both machines have nothing in common except it being Ubuntu 12.04 LTS and vim 7.3.

Really bizarre that it was all fine for the past month and now, within a week a couple of crashes on two distinct machines.

I am completely out of ideas. And given that it seems fine in vim 7.4, I would suggest that this is the "recommended workaround" for this? At least that way this ticket can be closed. Given the random nature of this bug, I don't see how we can effectively pinpoint the cause.

[dwf]

I'm seeing a version of this on Vim 7.3.315 on an old, old Fedora Core 14 install (my university department is horribly behind). Specifically, if I run :PymodeLint either by writing or manually, nothing seems to go wrong per se, but when I quit I do see

Vim: Caught deadly signal SEGV
Segmentation fault

printed on the console.

[AbeHandler]

I'm having this problem too.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closed due to inactivity.