Terminal.app crashing: Can I disable callbacks?

Hi Broomdodger, Yes, I have used MacVim, but not recently; the adventures documented here are strictly /usr/bin/vi

John

My intention is not to know if you previously tried MacVim, but to use the current version of MacVim with the Sierra terminal (or standalone) to see if it also caused the crashes. Reading your recent post I now understand vi[m] may not be the problem.

Upgrading to latest vim via Homebrew seems to have fixed this issue for me.

mattj_io wrote:

Upgrading to latest vim via Homebrew seems to have fixed this issue for me.

How long have you been testing this setup?

Do you have 'Secure keyboard entry' enabled in the Terminal menu?

I understand everyone is looking for a solution to this but it appears people are trying many different ideas with nobody testing the work of others.

Please consider starting tests with the basic option 'Secure keyboard entry'. If that works it will not be required to make system wide changes.

If that fails then use the older Terminal app or other versions of vim/ vi. Sakuro's post suggests it is wider than just vi/vim (git fails too).

If anyone is willing to risk it please consider installing a key logger & disable secure keyboard entry. It would be very useful to have a set of instructions that can trigger this crash - which may be related to the keyboard input.

I can say that with some certainty. I live in vi, and before this my terminal was crashing every 30 minutes or so. No crashes for the last 2 days. That's with vi 8.0 from homebrew with a forced source code compile.

That seems to be with Secure Keyboard Entry turned off. I've never used that and have no idea what it does, so haven't ever touched that setting.

mattj_io wrote:

That seems to be with Secure Keyboard Entry turned off. I've never used that and have no idea what it does, so haven't ever touched that setting.

Great, it wasn't clear if you had tried other suggestions from earlier in the thread.

From the Apple Help in Terminal…

So I had a day without crashes, which was nice, but was pleased to have reproduced the error again while running "script" on the remote system. This allowed me to capture the output that the shell on the remote machine was emitting. So I had a terminal window (one of many) up for around 4 hours, I was interacting solely with that window for 5 minutes or so when the terminal crashed. Interestingly it crashed as I was starting vim on the remote system.

I replayed the escape sequences just by issuing 'cat typescript.1' and also by writing a small program to print the characters one at a time interspersed with a small delay. Neither of those reproduced the crash. Given that the terminal went away, it is possible that ssh tore down the session and killed script before the final (buffered) characters were written, so I may have lost the really critical characters.

To be clear, on my local Mac after I opened terminal, I immediately used ssh to start a shell on a remote system and was working solely in that terminal on the remote system when Terminal crashed.

Hi all,

Just checking in with a (possibly meaningless) update. I have been using secure keyboard entry for 1-1/2 days now with no crashes, although my vi usage has only been light to moderate (15-30% of the time). I don't consider this remotely close to proof of a fix yet, just wanted you all to know the experiment continues. If I have still seen no crashes in a few more days, including at least a couple days of serious vi exercise, I'd perhaps be willing to believe secure entry might be a workaround. I don't know enough about secure entry to say how that is actually affecting the way in which keystrokes are delivered to Terminal, but it's hard to imagine there's a very big difference.

I don't think that I would expect crash frequency in general to be varied by working on a remote system inside your Terminal window -- in either case, your local Terminal is still processing all of your keystrokes as input and redrawing itself in response to your activities. It seems likely that it's one of these two things that is causing the crash, and we now have ample evidence that although vi usage may tickle the bug more than most Terminal children, it's not the root cause or even the only tickler.

Hi John

The easiest way is to use Homebrew ( http://brew.sh/ )

You'll need Xcode installed first, then install Homebrew, then just do :

brew install vim

That will probably pull down a pre-compiled version, but you can force it to recompile by doing :

brew install vim --build-from-source

I'm just using the standard compile flags from the Homebrew recipe. If you want python support in vi, you'll probably need to brew install python first.

I've trimmed the tail off of the stream for two instances, I was not able to catch a third where vi was not involved. I'm including a base64 gzipped version of those. Decode by copying into your pasteboard and then run "pbpaste | base64 -D - | gzcat > output_file_here.txt"

This is from vi (typescript.1)

H4sICGsOXFgAA3R5cGVzY3JpcHQuMS1zbWFsbADNlsFqhDAQQO9CvyCXsKceaslMJlorS9mllIVC

fyD0VAUL2kMXttDDfnsn4lZd7K06K5gYMvLGiTxGg713qUaIH8u3GBJ1vVW+UZ6SHHbKQ07Jp/L8

RC4nx/MDYM0juiqMxhCvkHjvFFZE49eKNjpEwUb556tooeEsVajUepQpUtGHwvZSptXt974qPw4r

7V/KL/30XpevZ+eA4WS6mg6+J1TaUnPUC16MDT/K0sxUgHknwMyWZ1ojwAQBJgow7czMoSgYltnd

yecDUXQbwRVTOZJAXZwAU8BbVsBbVsBbVsBbJOAtEvAW/aO3Rn0F5ilO6aLbmNTFXznO7bkpJrUN

q804e+A7bbpGag6cuTEx9MtNXf8m0Fe0bTAHPWhb2ugHw5igV3ELAAA=

And this is from vi editing the previous dump file (typescript.2):

H4sICKMPXFgAA3R5cGVzY3JpcHQuMi1zbWFsbADtlt9LwzAQx98H+wvyUvYkSKV3+VmDODaRgmz/

QHAvtjBh9UFBwb/eLHU0V5yZ4JgP9qFNvnefS67pJWVnM+Za5lBYqJi7Btz4O8o1c2C5eWbOq1xb

AO0b4D11a4Kt7GzIa/YZYy+gCYBpQBEA0oCMAShnSUAQANIAjwFxhAGOlULZrxvkhqQBaA2vkhwU

PIdCDkivpFFV8txIIKix6gBSg8yN5gPS6D0kQj+m58SQMz2Hlqv+pTm9iGN5KQN+KXWGkN80Dzn4

bxHnW5Zju3L+UbbbMFFPqFA7kQJWbIeIFGoX0gpJpa7yYiEUIRGKQlAfX7VCfj9Q7RvFcH53XW8x

Hv2KcngKQPpXP0sGRX1YFrtVmH3l/m88kXE1/nNT2mOcXLy/rJun10nmls1bvJVwZZWpwgm5IVtQ

0LPbx01zT0OndwIcFGcXmxaGb8iuiEU7zU5+hYShmp56HmEm2mJRhTe1OwHcuV+EUs1h50PPyfgv

JxwKow+4RzqvBgkAAA==

I tested 'Secure Keyboard Entry' with two cases.

In short, the crash *can happen with* Secure Keyboard Entry enabled.

In both cases I ssh-ed to a server ('remote') and 'tail -f'-ed a log file of nginx

which serves to decent amount of requests.

Case A (in tmux):

mac$ tmux

mac[tmux]$ ssh remote

remote$ tail -f /var/log/nginx/blahblah.access_log

Case B (not in tmux):

mac$ ssh remote

remote$ tail -f /var/log/nginx/blahblah.access_log

Case A frequently crashes, within seconds in the worst case.

Sometimes it immediately crashes again when I reattach the terminal to the crashed session with 'tmux a'

Case B does not seem to crash for 10 or more minutes.

I thought the ncurses library is the culprit becase both tmux and vim are linked to it,

but my tmux is linked to /opt/local/lib/libncurses.6.dylib from MacPorts

while /usr/bin/vim is (of course) linked to /usr/lib/libncurses.5.4.dylib :-/

I'm running Sierra 10.12.2 and suffering terminal crashes daily since the ".2" update.

The crashes always happen when I'm editing code, often when saving with ":w".

I have a big external monitor pretty much paved with terminal windows, several of which are running vim on different parts of my code base. Several terminals windows are generally logged into remote production servers, and I'm pretty sure I've had crashes editing files on those ssh'd systems as well as on my local MacBookAir6,2.

I'm going to pay more attention to which system's vim causes the crash, and exactly what my "automatic" fingers are actually doing to provoke the crash. (I'm also not very conscious of what my vim fingers are doing)

It sure is painful to crash terminal when I have so many open files and ssh sessions at a time!

My laptop's /usr/local/bin/vim is symlinked to MacVim 8.0, but the servers are running 7.3

My laptop:

:version

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Dec 9 2016 08:03:38)

MacOS X (unix) version

Included patches: 1-124

Compiled by root@Traviss-Mac-592.local

Huge version with MacVim GUI. Features included ➕ or not (-):

+acl +diff +jumplist +mouse_urxvt +scrollbind +virtualedit

+arabic +digraphs +keymap +mouse_xterm +signs +visual

+autocmd +dnd +lambda +multi_byte +smartindent +visualextra

+balloon_eval -ebcdic +langmap +multi_lang +startuptime +viminfo

+browse +emacs_tags +libcall -mzscheme +statusline +vreplace

++builtin_terms +eval +linebreak +netbeans_intg -sun_workshop +wildignore

+byte_offset +ex_extra +lispindent +num64 +syntax +wildmenu

+channel +extra_search +listcmds +odbeditor +tag_binary +windows

+cindent +farsi +localmap +packages +tag_old_static +writebackup

+clientserver +file_in_path +lua/dyn +path_extra -tag_any_white -X11

+clipboard +find_in_path +menu +perl/dyn -tcl -xfontset

+cmdline_compl +float +mksession +persistent_undo +termguicolors +xim

+cmdline_hist +folding +modify_fname +postscript +terminfo -xpm

+cmdline_info -footer +mouse +printer +termresponse -xsmp

+comments +fork() +mouseshape +profile +textobjects -xterm_clipboard

+conceal +fullscreen +mouse_dec +python/dyn +timers -xterm_save

+cryptv -gettext -mouse_gpm +python3/dyn +title

+cscope -hangul_input -mouse_jsbterm +quickfix +toolbar

+cursorbind +iconv +mouse_netterm +reltime +transparency

+cursorshape +insert_expand +mouse_sgr +rightleft +user_commands

+dialog_con_gui +job -mouse_sysmouse +ruby/dyn +vertsplit