Terminal.app crashing: Can I disable callbacks?

Heya!

This problem's been bugging me as well and with the information from this thread I narrowed it down to the following:

Stuart's test case can be simplified to the following:

1. Open vim an enter three lines of arbitrary text such as this:
   a
   a aaaaaaaaaaaaaaaaa
   a
   - First and third line just have to be present - no idea why.
   - The second line needs to have a space as the second character and wrap exactly one character to the next line.
   
2. Delete the first character of the second line by pressing x so that now the line starts with a space and the last character of the line moves to the last column of the terminal.
   
3. Wait about a second and Terminal.app will crash.

This suggests that Terminal.app has for some reason problems with lines that start with a space and end on the last column of the terminal.

It also only seems to relate with redrawing of the screen because I was not able to reproduce it with echo commands from the command line and I have only ever seen it with full-screen terminal applications like vim and screen, running both locally and remotely.

I had a suspicion it was related to the alternate screen which both vim and screen use by default. I was able to rule that out by setting TERM=vt100 to disable use of the alternate screen and still being able to trigger the crash as described above.

The problem seems to have been introduced with Terminal.app 387 of the 10.12.1 update. I extracted version 377 from my recovery partition (also present in the original 10.12.0 installer) which copes fine with above test case.

The obvious difference between both versions when diff'ing output of the strings command on both executables it the additon of Touchbar functionality mostly relating to man page interaction. I was not able to find any knob to disable this functionality to further narrow down the cause.

Thanks everyone for their research, providing a simple and reproducible test case and the workaround of going back to version 377 for now,

Michael

This is happening to me a great deal (Terminal is crashing when I run VIM), and I badly need a workaround.

The following is 100% repeatable for me. Create a text file with the following content (Cut & paste into vim, for example) between the --- lines:

---

This is a test of a line which might reproduce the Terminal crash by being just over

80 columns

---

This should be exactly 3 lines long, the first line is empty, and the second line is just over 80 columns long, the third line is "80 columns". Save this file as "test_file".

Size your Terminal window so it is 80 columns wide exactly. Run vim on the file:

vi test_file

Move to line 2, "This is a test..", to the first T. Press 'x' four times. Terminal will crash. The crash occurs as the line goes from 81 characters (so it wraps to the next line) to 80 characters.

I found a simple test case which reliably crashes Terminal while typing in vim, under 10.12.3 on my Macbook Pro. It happens whether using macos-supplied vim, or a linux copy of vim run remotely via ssh.

Repeat-by:

Make a Terminal window that’s not too wide, e.g. 120 columns. This example doesn’t crash in a 150-column-wide terminal, but does for a variety of smaller width.

Edit the following plain ASCII text file. Since I don't see a way to attach a file, and I can't prevent auto-wrapping, I'm including it in-line bracketed by ====’s, which should be removed. Also, each line ends with the line number in square brackets, to make it clear where the line breaks are. That is, if you've copied-and-pasted it successfully, this text file is exactly 5 lines long, with the longest being 259 characters. A suitable example file is also downloadable at http://dart.ncsa.uiuc.edu/slevy/edit-to-crash-terminal.txt:

===

/goldbaum2-7.bmv already exists; use -y to recreate [1]

/des_surveyBuildup_11-7.bmv already exists; use -y to recreate [2]

/lsst_telescope12-22.bmv 1-2660 /fe0/deslsst/telescope/comps/lsst_obj_12-22_comp4k/lsst_obj_12-22_comp4k.%04d.p ng [3]

img2bmv -f 30 -p 3 -N 6 -L 42 -t 512x360 -w 4096x2160 -w 3840x2160 -t 480x540 -o /fraid0/movies/ren400My_vars_grids_labels_11-8.bmv 1-2881 /fe0/deslsst/renaissance/comps/ren400My_vars_grids_labels_3840_11-8/ren400My_va rs_grids_labels_3840_11-8.%04d.png [4]

Don't know how to make these movies: -f 3 [5]

====

In any case, in vim, type:

3jdfo

i.e., go down to the 4th line, then delete from start-of-line to the first “o”.

Terminal crashes reliably!

Now you have a reliable method to reproduce I'd consider reporting to Apple again…

Contact Apple About Security Issues - Apple Support

Perhaps the product-security email is appropriate here? From what I can tell certain crashes can potentially be manipulated into other compromises that can allow more access to other parts of the system.

If you are frustrated by Apple's silence & apparent lack of progress you could look around for Mac security researchers, they may investigate this & try to claim Apple's bug bounty if it can be found to compromise the system. Since these topics are public it may just be a matter of time before anyone starts to look into that anyway. The Apple Software updates have a list of researchers that have given responsible disclosure…

About the security content of macOS Sierra 10.12.3 - Apple Support…

Vim

Available for: macOS Sierra 10.12.2

Impact: Opening a maliciously crafted file may lead to unexpected application termination or arbitrary code execution

Description: An input validation issue existed in modelines. This was addressed through improved input validation.

CVE-2016-1248: Florian Larysch

Is this related at all? Is there any change after installing the 10.12.3 update (not a beta version)?

There are about 3 workable treatments posted by various in the following thread, none "cure vim" per say.

Re: Terminal.app keeps crashing while using VIM

This is possibly an "unwatched/inactive thread" posted in 2016, but the question always is: how is the issue repeatable? (ie, for vim(1) it was noted that crashing occurs in Linux based OS and Sierra OS using vim(1) but not all other terminal emulators (iTerm2) + vi clone mixtures (elvis(1) seems to work fine on linux and Sierra using Terminal.app). Sierra termcap/terminfo settings maybe not matching vim/ncurses also a possible.)

AFAIK all of my Terminal crashes have happened while I was in vi, although I do normally have several shells open at the same time. It usually happens at least once a day, but happened a few times today. Next time it happens I will look at the backtrace and compare with yours. I have already sent a couple of them to Apple, no reply yet. My system is not new, so I have no phone support.

I'm seeing it on my Macmini running Sierra (oddly not on my Macbook Pro running ElCap).

It's always in "vi". It doesn't matter if I'm running the vi locally or on a remote machine via ssh.

I see this crash 5 or 6 times a day.

I suspect that the terminal emulation in Terminal.app is broken, in that it gets either

1. an escape sequence it's not expecting, leading to undefined behavior like a bad table indirection;
2. that the escape sequence is being split up over 2 packets (less likely), and not all the data arrives before the terminal emulation tries to parse the sequence but this is very speculative;

If it's (1) then it should be trivial for Apple to dig out of a core dump what the input data stream was at the moment that Terminal crashed from a coredump.

Who knew a 1980's technology like terminal emulation was so challenging? 😮

-Philip

Amazing thread with lots of good troubleshooting!

I should note that this is happening to me as well, 10-20x a day.

My solution (other than waiting for Apple to fix this) is to use screen, which I use reflexively anyway. After the crash it takes about a second to reopen Terminal and 'screen -r' to resume what I was doing before.

I can reliably provoke this problem with a fairly simple routine.

Start by running a screen session on your server, and irssi inside screen. SSH in, then let your laptop go to sleep. Wait long enough, and SSH will disconnect on resume, which leaves the terminal in a broken state where only the last line updates.

Ctrl-L fixes it, but traditionally I've just pressed up-return to resume my ssh session; something irssi does then will also fix the terminal. However, with this bug, doing so will instead crash Terminal.app. Press ctrl-L first, and it won't crash.

I'm having similar problems, using vi on a remote machine that I connect to using ssh. Interestingly, I didn't have those problems when I was using the same setup under Sierra 10.12 rather than 10.12.2. I see that Terminal.app has changed between the two versions of Sierra. The Terminal.app under Sierra 10.12 is 2.7 (377). The Terminal.app under 10.12.2 is 2.7.1 (388).

My husband's having the same problem: connecting to a remote host via ssh. Thankfully, he's using screen on the remote end, so he's not losing his work. Here's the traceback from the crashing thread (20 crashes today, yay):

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0 libsystem_platform.dylib 0x00007fffe2c52f56 _platform_memmove$VARIANT$Haswell + 182

1 com.apple.Terminal 0x0000000108d94c4d 0x108d5c000 + 232525

2 com.apple.Terminal 0x0000000108df2bb8 0x108d5c000 + 617400

3 com.apple.UIFoundation 0x00007fffe005cb7f -[NSAttributedString(NSAttributedStringUIFoundationAdditions) doubleClickAtIndex:inRange:] + 337

4 com.apple.AppKit 0x00007fffcb5e690e -[NSAttributedString(NSAttributedStringDeprecatedKitAdditions) URLAtIndex:effectiveRange:] + 607

5 com.apple.Terminal 0x0000000108e00625 0x108d5c000 + 673317

6 com.apple.Terminal 0x0000000108dcbf81 0x108d5c000 + 458625

7 com.apple.Terminal 0x0000000108dcc1e9 0x108d5c000 + 459241

8 com.apple.Terminal 0x0000000108dd2c1c 0x108d5c000 + 486428

9 com.apple.Foundation 0x00007fffcef7ef7f __NSFireTimer + 83

10 com.apple.CoreFoundation 0x00007fffcd4f3244 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20

11 com.apple.CoreFoundation 0x00007fffcd4f2ecf __CFRunLoopDoTimer + 1071

12 com.apple.CoreFoundation 0x00007fffcd4f2a2a __CFRunLoopDoTimers + 298

13 com.apple.CoreFoundation 0x00007fffcd4ea3e1 __CFRunLoopRun + 2065

14 com.apple.CoreFoundation 0x00007fffcd4e9974 CFRunLoopRunSpecific + 420

15 com.apple.HIToolbox 0x00007fffcca75acc RunCurrentEventLoopInMode + 240

16 com.apple.HIToolbox 0x00007fffcca75901 ReceiveNextEventCommon + 432

17 com.apple.HIToolbox 0x00007fffcca75736 _BlockUntilNextEventMatchingListInModeWithFilter + 71

18 com.apple.AppKit 0x00007fffcb01bae4 _DPSNextEvent + 1120

19 com.apple.AppKit 0x00007fffcb79621f -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2789

20 com.apple.AppKit 0x00007fffcb010465 -[NSApplication run] + 926

21 com.apple.AppKit 0x00007fffcafdad80 NSApplicationMain + 1237

22 libdyld.dylib 0x00007fffe2a42255 start + 1

I set Terminal --> Secure Keyboard Entry (checked "on") and have not had any crashes for a week or so.

But I just did, while in vim. In this time I'm pretty sure I know what my fingers were doing :-)

It was a local-to-my-laptop vim (MacVim 8.0) session, I had just yanked a line with 50 or 60 characters, scooted to location about a dozen lines away, and typed a command of ctrl-A to Append, and then two spaces followed by two ampersands. The crash seemed to occur on the second ampersand.