I live my life in Vim.
And since getting a new laptop with Sierra pre-installed, life has had
difficulties. All these happened while I was inside of vim:
$ ls -1 Ter*sh
Terminal_2016-12-06-111816_hostname.crash
Terminal_2016-12-06-123823_hostname.crash
Terminal_2016-12-07-115856_hostname.crash
Terminal_2016-12-07-181545_hostname.crash
Terminal_2016-12-07-181912_hostname.crash
Terminal_2016-12-08-125817_hostname.crash
Terminal_2016-12-08-130034_hostname.crash
Terminal_2016-12-08-130845_hostname.crash
Terminal_2016-12-08-210156_hostname.crash
Terminal_2016-12-08-214326_hostname.crash
Terminal_2016-12-08-215326_hostname.crash
Terminal_2016-12-12-175135_hostname.crash
Terminal_2016-12-14-132746_hostname.crash
Terminal_2016-12-14-170328_hostname.crash
Terminal_2016-12-14-201951_hostname.crash
Terminal_2016-12-15-061513_hostname.crash
Terminal_2016-12-15-064843_hostname.crash
Terminal_2016-12-15-090621_hostname.crash
$
There is a great deal more information, including summaries of the call stacks
from the above, at the thread
'Terminal.app crashing: Can I disable callbacks?'
at the macOS Sierra apple support community
https://discussions.apple.com/message/31112173
Up until today, it had not occurred to me that Vim might be at "fault" or even
remotely close to being the cause. I figured it was just the victim. However,
a new complainant has just joined the thread (RogerDavis) who reports that he
is also seeing Terminal.app crash while running Vim. While neither of us can
really see how it could be Vim's fault, having worked with Editors for a while,
I just posted this bit of
Speculation:
Meanwhile, you ask, how could it possibly be the editor's fault if the Terminal
crashes. Good question. I can vaguely imagine that perhaps in the interest of
performance, there might be code paths in vim+curses+Terminal that optimize
screen re-drawing, which are pushed hard by this highly-optimized editor, and
which were not pushed by whoever did QA on Terminal. (Once upon a time, it was
very important that Editors know a lot about the underlying device, because you
were much better off telling the VT100 to do this rather than that; or much
better off sending this series of characters at 2400 baud than that series.)
BINARY
Here are the details about the Vim on MacOS Sierra 10.12.1:
$ which vi
/usr/bin/vi
$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 Oct 21 06:10 /usr/bin/vi -> vim
$ ls -l /usr/bin/vim
-rwxr-xr-x 1 root wheel 1745984 Oct 21 05:07 /usr/bin/vim
$ /usr/bin/vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 19 2016 15:09:36)
Included patches: 1-898
Compiled by [email protected]
Normal version without GUI. Features included (+) or not (-):
+acl -farsi -mouse_netterm +syntax
-arabic +file_in_path -mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
-balloon_eval +float -mouse_urxvt -tag_any_white
-browse +folding +mouse_xterm -tcl
+builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent -gettext -mzscheme +textobjects
-clientserver -hangul_input +netbeans_intg +title
-clipboard +iconv +path_extra -toolbar
+cmdline_compl +insert_expand -perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info -keymap +postscript +virtualedit
+comments -langmap +printer +visual
-conceal +libcall -profile +visualextra
+cryptv +linebreak +python/dyn +viminfo
+cscope +lispindent -python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con -lua -rightleft +windows
+diff +menu +ruby/dyn +writebackup
+digraphs +mksession +scrollbind -X11
-dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent -xim
-emacs_tags -mouseshape -sniff -xsmp
+eval -mouse_dec +startuptime -xterm_clipboard
+ex_extra -mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop -xpm
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -o vim -lm -lncurses -liconv
$
QUESTIONS:
(1) Do you see anything risky about how '[email protected]' chose to compile? The
above compilation string differs remarkably from the string in the the Vim that
came with El Capitan:
$ /Volumes/20161202_BootableJohnMacPro/usr/bin/vi --version | head -2
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 14 2016 16:06:49)
Compiled by [email protected]
$ /Volumes/20161202_BootableJohnMacPro/usr/bin/vi --version | tail -3
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -D_FORTIFY_SOURCE=0 -Iproto -DHAVE_CONFIG_H -arch i386
-arch x86_64 -g -Os -pipe
Linking: gcc -arch i386 -arch x86_64 -o vim -lncurses
$
Notice that the El Capitan version used '-Os', which is slightly less
aggressive than the '-O2' in the Sierra version; and differs in regards to
FORTIFY_SOURCE and the presence of libiconv
(2) If I turn on keystroke tracing (vim -w keys.out) is that likely to be
useful? That is, will it be 'current' at the time of the crash? (I'm guessing
not, unless vim gets a chance to flush its buffer when Terminal goes away.)
(3) Any suggestions?
--
--
You received this message from the "vim_mac" 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_mac" 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.
