Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

vim crashes with segfault when completing sys #27

Closed
dbrgn opened this Issue Oct 23, 2012 · 28 comments

Comments

Projects
None yet
6 participants
Collaborator

dbrgn commented Oct 23, 2012

Probably closely related to #17.

Vim crashes with a segfault when completing sys.

import sys
sys.<tab>

The corresponding jedi completion works:

>>> jedi.Script('import sys\nsys.', 2, 4, 'test.py').complete()
[<Completion: long_info>,
...]

I just switched from pathogen to vundle. I thought that this didn't happen before, but I reverted my configuration and vim still crashes.

Collaborator

dbrgn commented Oct 23, 2012

Steps to reproduce environment with only pathogen and jedi-vim installed (without any preexisting vim configuration):

mkdir -p .vim/autoload .vim/bundle

curl -Sso ~/.vim/autoload/pathogen.vim \
https://raw.github.com/tpope/vim-pathogen/master/autoload/pathogen.vim

echo 'call pathogen#infect()
syntax on
filetype plugin indent on' >> .vimrc

git clone git://github.com/davidhalter/jedi-vim.git .vim/bundle/jedi-vim

vim test.py

Then do the completion above.

Collaborator

dbrgn commented Oct 23, 2012

Bug disappeared after recompiling vim.

@dbrgn dbrgn closed this Oct 23, 2012

pag commented Dec 17, 2012

I have the same problem with Vim 7.3 64 bit on Windows. It worked fine with MacVim when I was using it yesterday. It's not quite so easy for me to recompile Vim on Windows. I can :py import sys; print dir(sys) just fine, not sure what else to try.

Owner

davidhalter commented Dec 19, 2012

@pag Could you try :py import sys, inspect; print dir(sys)

:py import sys; print [getattr(sys, d) for d in dir(sys)]

and

:py import sys, inspect; print [inspect.getdoc(getattr(sys, d)) for d in dir(sys)]

and we'll also try:

:py import sys, inspect; print [(x, getattr(d, x), inspect.getdoc(getattr(d, x))) for d in dir(sys) for x in dir(getattr(sys, d)) if hasattr(d, x)]

I hope one fails. Because that's what I'm doing.

pag commented Dec 20, 2012

Those all run fine. Would you like to see their output? I can try to find the crashing line if you have no other ideas.

Owner

davidhalter commented Dec 20, 2012

I can try to find the crashing line if you have no other ideas.

Yeah that would be great! I'd start at builtin.py#265. The error happens probably there.

pag commented Dec 20, 2012

The crash is in the variables section of ''jedi.builtin._generate_code'', when it tries to do the equivalent of ''type(sys.stdout)'', which I can confirm crashes gvim. It also crashes vim.exe.

Owner

davidhalter commented Dec 20, 2012

So :python print type(sys.stdout) crashes gvim and vim.exe?

Because if that's so, I'm going to post this on the VIM mailing list.

pag commented Dec 20, 2012

Yes, that's right (I didn't realise that sys was imported by default). It still happens when I start vim with -u NONE, so it's not caused by any other config or plugin.

Owner

davidhalter commented Dec 20, 2012

@ranveer5289 Can you please try to reproduce this in your windows setting? -> :python print type(sys.stdout).

I'm speaking about this: #7 (comment) (Problems with Windows).

Owner

davidhalter commented Dec 20, 2012

@pag Can you supply your output from :ver? (If possible in both vim.exe and gvim)

Owner

davidhalter commented Dec 25, 2012

@pag ping Can you supply your output from :ver? (If possible in both vim.exe and gvim)

pag commented Dec 25, 2012

Sure, here's gvim

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 16 2010 10:31:31)
MS-Windows 64-bit GUI version with OLE support
Compiled by george@reilly.org
Huge version with 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 +gettext/dyn -hangul_input
+iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse
+mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole
-osfiletype +path_extra -perl +persistent_undo +postscript +printer +profile
+python/dyn -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim
-xterm_save -xpm_w32
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
    user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
    system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   -DFEAT_CSCOPE
-DFEAT_NETBEANS_INTG      -DWINVER=0x0400 -D_WIN32_WINNT=0x0400  /Fo.\ObjGOY/ /Ox /GL -DNDEBUG 
/Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_MBYTE -DFEAT_GUI_W32
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON 
-DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DMSWINPS -DFEAT_HUGE /Fd.\ObjGOY/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib
shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:AMD64 /nodefaultlib gdi32.lib version.lib  
winspool.lib comctl32.lib advapi32.lib shell32.lib  /machine:AMD64 /nodefaultlib libcmt.lib oleaut32.lib  user32.lib

vim

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 16 2010 10:30:12)
MS-Windows 64-bit console version
Compiled by george@reilly.org
Huge version without 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 +diff +digraphs
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +float +folding -footer +gettext/dyn -hangul_input +iconv/dyn
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape
+multi_byte_ime/dyn +multi_lang -mzscheme -netbeans_intg -osfiletype
+path_extra -perl +persistent_undo +postscript +printer +profile +python/dyn
-python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title
-toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim
-xterm_save -xpm_w32
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   -DFEAT_CSCOPE       -DWINVER=0x0400 -D_WIN32_WINNT=0x0400  /Fo.\ObjCY/ /Ox /GL -DNDEBUG  /Zl /MT -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_MBYTE -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON  -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DMSWINPS -DFEAT_HUGE /Fd.\ObjCY/ /Zi
Linking: link /RELEASE /nologo /subsystem:console /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:AMD64 /nodefaultlib  libcmt.lib   user32.lib      /nodefaultlib:python27.lib       /PDB:vim.pdb -debug

@davidhalter : :python print type(sys.stdout) crashes my gVim 7.3 also.

Owner

davidhalter commented Dec 26, 2012

Can you also send me :ver?

And @ranveer5289 and @pag can you try this in python to check if that's also killing python?

pag commented Dec 26, 2012

Yes, naturally it's not killing Python.
On 26 Dec 2012 10:52, "David Halter" notifications@github.com wrote:

Can you also send me :ver?

And @ranveer5289 https://github.com/ranveer5289 and @paghttps://github.com/pagcan you try this in python to check if that's also killing python?


Reply to this email directly or view it on GitHubhttps://github.com/davidhalter/jedi-vim/issues/27#issuecomment-11684515.

Owner

davidhalter commented Jan 4, 2013

I posted it on the VIM mailing list a while ago, but no answer yet:
http://thread.gmane.org/gmane.editors.vim/109301

as requested her is the output of :ver on my system

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-46
Compiled by Bram@KIBAALE
Big version with 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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand 
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole 
-osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff +startuptime 
+statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
 +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save +xpm_w32 
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
    user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
    system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG   -DFEAT_XPM_W32   -DWINVER=0x0400 -D_WIN32_WINNT=0x0400  /Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG  /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=\"tcl83.dll\" -DDYNAMIC_TCL_VER=\"8.3\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python31.dll\" -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl512.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\" -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib version.lib   winspool.lib comctl32.lib advapi32.lib shell32.lib  /machine:i386 /nodefaultlib libcmt.lib oleaut32.lib  user32.lib      /nodefaultlib:python27.lib /nodefaultlib:python31.lib   e:\tcl\lib\tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug

i tried doing.

:py import sys; print sys.path

and it worked as expected so i know the internal interpreter of vim is cool with the modual being loaded and used.

Owner

davidhalter commented Jan 5, 2013

@cmcpasserby Can you try :python print type(sys.stdout), that's what would be interesting.

@davidhalter davidhalter reopened this Jan 5, 2013

@davidhalter and that caused a crash just like what happens when completing the modual.

if i dont query the type it just return a message object at some memory address.

from my systems python interpreter not vi's i get type 'file'

think you might be able to reclose this, it defently isnt your problem, i grabbed the latest vim sources from there mercurial repo and compiled myself, agaisnt the python 2.7.3, and i no longer get this segfault and completion now works for the sys modual

Owner

davidhalter commented Jan 5, 2013

Hmmm. Maybe the bug has been fixed. I'm not closing right now, because it really is a problem for multiple people (even if it's not my fault).

ya the issue seems to be only a problem with the pre-compiled vim that comes from here http://www.vim.org/download.php#pc

getting the latest code from the repos, and self compiling fixes it or grabbing it from here http://tuxproject.de/projects/vim/ will also give a version that doesn't have the segfault with the sys modual.

so would be nice if there was a way to contact the people running the vim site, so atleast they know about that bug.

Owner

davidhalter commented Jan 7, 2013

To everyone who is experiencing this bug, as written in this discussion: http://thread.gmane.org/gmane.editors.vim/109301, please use a newer version of vim/gVim.

Tony Mechelynck wrote this:

This one is long-obsolete 7.3.046 32-bit Windows version from Bram's
site. The other was apparently 7.3.000 64-bit Windows version (so from
an even more obsolete source). As you can see from the first line, this
one was compiled on 27 October 2010 and the other two on 16 August 2010.

For Win32 (or W32 running on W64) I recommend the (currently 7.3.762)
"Vim without Cream" by Steve Hall, available from
http://sourceforge.net/projects/cream/files/Vim/

For a list of the (currently 762) already published bugfixes to Vim 7.3,
see http://ftp.vim.org/pub/vim/patches/7.3/README

If you're still seeing this problem those new versions, please let me know.

@davidhalter davidhalter closed this Jan 7, 2013

pag commented Jan 7, 2013

If the gvim version is so old that bugs like that can be shrugged off with a "not supported", then why is it linked to from the Vim website? I need to use a 64-bit version of Vim because a plugin that I'm using needs the memory. The Vim website doesn't suggest any place to find more recent ones. I'll look around, but it's not an ideal solution. I appreciate there's not much that you can do about it though!

Owner

davidhalter commented Jan 7, 2013

@pag Yeah... Why don't you write that as an answer to my postings to the VIM mailing list?

pag commented Jan 8, 2013

After a bit more searching I found the Wiki page at http://vim.wikia.com/wiki/Where_to_download_Vim, which links to a more recent source of Win7 64 bit binaries at https://bitbucket.org/Haroogan/64-bit-vim-builds-for-windows-64-bit.

Just wanted to note that this does seem to be an issue with the version of vim that ships with OS X 10.7, even if you've recompiled it at some point downstream (in my case, in June of 2012). I'm going to try to use the Homebrew dupe tap to get a new version and see if that improves my situation later tonight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment