You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

john henning Author

Level 1

21 points

Terminal.app crashing: Can I disable callbacks?

Five times in the last 48 hours, Terminal.app "quit unexpectedly". The Terminal_datestamp.crash files show

EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x0000000000000000

with a call stack that always includes:

com.apple.Terminal 0x000000010530bc94 0x105295000 + 486548 com.apple.Foundation 0x00007fff972ac5df __NSFireTimer + 83 com.apple.CoreFoundation 0x00007fff95837d74 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 com.apple.CoreFoundation 0x00007fff958379ff __CFRunLoopDoTimer + 1071 com.apple.CoreFoundation 0x00007fff9583755a __CFRunLoopDoTimers + 298 com.apple.CoreFoundation 0x00007fff9582ef81 __CFRunLoopRun + 2065

User impact

I cannot use the system: must find solution, even if the cost is to wipe disk and install previous OS (El Capitan).

The primary question

(q1) Is there some new feature of Sierra that integrates Terminal with other apps that can be turned off, perhaps a setting to disable callbacks?

Secondary questions

(q2) Can I potentially run a copy of the Terminal.app from a previous version of Mac OS X? Prior to my new laptop (and Sierra) these crashes never happened.
(q3) What additional detail would be useful, and how can I collect it?
I am familiar with Unix application development, but not for Mac OS X. I am happy to collect additional detail by turning on debug tools, traces, event collectors, etc. but would need pointers to get started. Xcode is available, but I would be a beginner with it.

System summary

New MacBook Pro (Retina, 15-inch, Mid 2015).
- Arrived 6 days ago.
- (Yes, I intentionally bought a brand-new instance of the previous model.)
- Surprisingly, it arrived with Sierra. It presently has 10.12.1
- Xcode installed
- GCC 6.2.0 available, built locally.
Previous history brought in by Migration Assistant
Not tried (yet, anyway)
- I have briefly visited safe mode but have not stayed there. I do not know whether there would be crashes of Terminal.app if I spent all day in safe mode
- I do not know whether there would be crashes if I created a fresh, different user account.
Tentative rule-outs:
- Malware, adware, etc are reasonably unlikely given the usage pattern for this work system: firewalls in sw and hw, no visiting of dicey websites, primary application used all day long is vim.
- However, if Terminal is now integrated with the world wide web then I suppose anything is possible.

MacBook Pro with Retina display, macOS Sierra (10.12.1)

Posted on Dec 8, 2016 7:06 AM

Top-ranking reply

michaelweiser

Level 1

4 points

Posted on Feb 19, 2017 4:53 AM

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:

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.
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.
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

View in context

193 replies

Dec 15, 2016 7:45 PM in response to RogerDavis

PPS: I did one other experiment today. After getting sick of having my editor crashing repeatedly, I used my laptop (still running ElCap because it's just barely too old to upgrade to Sierra, and maybe that's not a bad thing now ;-> ) to ssh into my desktop and edit that way. I did this for a few hours with no crashes, but that's probably not long enough to qualify as a serious workout. So, on my ElCap laptop I was running Terminal running tcsh running ssh, and on my problematic Sierra desktop I was running vi under that ssh.

I may continue working this way for a few days, maybe if I have no crashes either in the editor or in the non-vi Terminal windows still open on my Sierra desktop doing other tasks, that will say something useful.

Drew Reece

Level 6

10,666 points

Dec 15, 2016 8:39 PM in response to RogerDavis

Have you tried other Terminal apps?

You'll find some suggestions at…

http://alternativeto.net/browse/search/?q=terminal%20&platform=mac

I also wonder does it work if you ssh into the same machine? Not sure what that would tell you but it may be another datapoint?

Dec 15, 2016 9:36 PM in response to Drew Reece

Hi Drew,

Haven't looked at alternate terminal software yet (other than xterm, which is a bit stodgy even for me) but I sure will if this keeps up -- thanks for the reference! Hopefully it won't come to that. I'm not using Terminal any differently under Sierra than I have for the last several years on multiple preceding major MacOS releases. If Apple can't build a Unix system with a working terminal application I'd say that's a major problem, so hopefully they will put some work into fixing this.

Not sure what you mean by I also wonder does it work if you ssh into the same machine? Do you mean have I sat in front of my Sierra desktop, opened Terminal, and used it to ssh back into the very same Sierra host in loopback-ish fashion? That might be another interesting experiment to try at some point, perhaps.

Although both John and I seem to be having this problem while using vi, I really don't see how even the world's worst-behaved child process can be responsible for crashing its grandparent (via tcsh as the intermediate parent, in my case at least) under anything but the most exceptionally unusual circumstances. I don't really know much about MacOS GUI event dispatching, but I should think that Terminal remains an intermediary in passing keystrokes down into vi somehow. Perhaps the individual keystrokes being used are important here, like <ESC> and/or other control characters. I will try to be more careful in my typing to see if there is a common keystroke pattern that is causing this.

Roger

Drew Reece

Level 6

10,666 points

Dec 15, 2016 10:47 PM in response to RogerDavis

RogerDavis wrote:

Not sure what you mean by I also wonder does it work if you ssh into the same machine? Do you mean have I sat in front of my Sierra desktop, opened Terminal, and used it to ssh back into the very same Sierra host in loopback-ish fashion? That might be another interesting experiment to try at some point, perhaps.

Yes exactly that, 'ssh your-user@localhost' should do it.

I don't know what difference it will make but I wonder as you said ssh worked from the other Mac.

My vi skills are terrible, which is why I suggest you try another emulator. I know Apple's app should work but I think it would be useful to see if the same crash happens in iTerm etc. It could be an issue with the shell or other processes I guess.

john henning Author

Level 1

21 points

Dec 16, 2016 3:09 AM in response to RogerDavis

Roger: *thank* *you* for the independent confirmation, and, especially, the confirmation that you are using vim during the crashes.

Three things.

Your crashes should still be around. Look in ~/Library/Logs/DiagnosticReports/Ter*
Much further upthread, Barney suggested 'iTerm2'. I have just started using it, and it seems much more promising than xTerm. I would click the 'helpful' button under that post of his, but it is grayed-out for me. I guess I cannot mark more than a few as helpful.
Knowing that you are also experiencing the crashes in vim has just accelerated my interest trying out this possibility, from my complete backup of my El Capitan system:

$ which vi
/usr/bin/vi
$ /usr/bin/vi --version | head -3
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 19 2016 15:09:36)
Included patches: 1-898
Compiled by root@apple.com
$ 
$ /Volumes/20161202_BootableJohnMacPro/usr/bin/vi --version | head -3
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 14 2016 16:06:49)
Compiled by root@apple.com
Normal version without GUI.  Features included

I will try 7.3 and will let you know whether it improves things.

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.)

john henning Author

Level 1

21 points

Dec 16, 2016 8:27 AM in response to john henning

Rule-outs: Hardware. User. Migrated Environment. Installed apps. VPN.

Just thought of an instructive test (not mentioned before now in this thread). Using:

My old, year 2012 Retina 15 inch MacBook Pro
Freshly-wiped, nearly empty internal disk
macOS Sierra 10.12.1
Additional apps: Xcode. A locally-built copy of gcc6.2. Approximately nothing else - in particular, Cisco AnyConnect is *not* present.
/usr/bin/vi 7.4 (as delivered by Sierra)

And ... we have a crash:

$ pwd

/Users/admin/Library/Logs/DiagnosticReports

$ ls Te*

Terminal_2016-12-16-110258_admins-MacBook-Pro.crash

This crash is with:

The old (year 2012) laptop, which lets us rule out the new hardware.
A new user account, not my old one - thus tending to rule out migrated oddities.
Very few other apps - in particular, it lets us rule out VPN.

Dec 16, 2016 9:30 AM in response to john henning

Hi John,

Thank you for posting this thread and spending so much time investigating the issue! I am very surprised that there are not more reports about this anywhere, it certainly whacked me over the head right after upgrading to Sierra.

A couple more things to potentially rule out or investigate further: are you using FocusFollowsMouse or tcsh like I am?

john henning Author

Level 1

21 points

Dec 16, 2016 9:54 AM in response to RogerDavis

Hi Roger,

Nope, bash user here, and have not adjusted the Focus setting.

-John

Drew Reece

Level 6

10,666 points

Dec 16, 2016 10:05 AM in response to john henning

Do either of you have 'Secure keyboard entry' enabled? It's in the Terminal menu. Toggle that, retest and post the results.

I wonder if it is time that a full crash log was posted? I can't diagnose them but someone else may have some insight.

john henning Author

Level 1

21 points

Dec 16, 2016 10:40 AM in response to Drew Reece

Secure Keyboard

Drew, 'Secure Keyboard' is an excellent thought and very apropos of my original concern: I came here wondering if Terminal is somehow integrated with other things in a way that is causing the breakage. From the help: "Secure keyboard entry can prevent other apps on your computer or the network from detecting and recording what you type in Terminal."

It looks like that is UNchanged for me: was off in 10.11 and is off now in 10.12.

I might try turning it on later; but for now am in the midst of a different experiment. Roger might want to try this too.

Using Vim 7.3 on Newer OS

This is not conclusive, but it is interesting that in about 90 minutes of using the older version of Vim, there have not (yet) been Terminal crashes.

Setup:

copy /usr/bin/vi from the old disk to some directory on the new disk, and give it the usual three names (vi, vim, vimdiff). You can use hard links, soft links, or actual multiple copies.
copy the subtree /usr/share/vim from the old disk - for example something like mkdir ~/oldvim/share; cp -pr /Volumes/my.old.El.Capitan.boot.disk/usr/share/vim ~/oldvim/share
At this point, you should have something like the structure shown below.
Define handy aliases (explained at bottom)

$ pwd

/Users/admin/oldvim

$ ls -l

total 3008

drwxrwxrwx 3 admin staff 102 Dec 16 12:01 share

-rwxrwxrwx 1 admin staff 1530064 Jul 8 22:52 vi

lrwxrwxr-x 1 admin staff 2 Dec 16 12:00 vim -> vi

lrwxrwxr-x 1 admin staff 2 Dec 16 12:01 vimdiff -> vi

$ ls share

vim

$ ls share/vim

vim73 vimrc

$ alias | grep vi

alias vi='VIM=/Users/admin/oldvim/share/vim /Users/admin/oldvim/vi'

alias vim='VIM=/Users/admin/oldvim/share/vim /Users/admin/oldvim/vim'

alias vimdiff='VIM=/Users/admin/oldvim/share/vim /Users/admin/oldvim/vimdiff'

To explain the aliases: when Vim starts up, it wants to find syntax files, language info, help text, colors - many useful things. The command runs the older version with VIM=/path/to/copied/share/vim in its environment. It does not permanently insert that symbol into your environment; it does so only for the command that is part of that alias.

john henning Author

Level 1

21 points

Dec 16, 2016 10:51 AM in response to john henning

"I wonder if it is time that a full crash log was posted? I can't diagnose them but someone else may have some insight."

Hi Drew, Sorry if this is a dumb question. You probably noticed that I was going to a bit of trouble to do trimming and subsetting; that is because I thought it was impolite to post full output here. However, if someone actually wants that, how can I upload this tarball, which contains 19 crashes, 1.2 megabytes of data, and is nicely compressed down to just 100 kb?

$ ls TerminalCrashes/T*sh | wc -l

$ du -hs TerminalCrashes/

1.2M TerminalCrashes/

$ tar cf - TerminalCrashes | bzip2 > TerminalCrashes.tar.bz2

$ ls -lh TerminalCrashes.tar.bz2

-rw-rw-r-- 1 admin staff 100K Dec 16 13:47 TerminalCrashes.tar.bz2

Drew Reece

Level 6

10,666 points

Dec 16, 2016 11:51 AM in response to john henning

You are mostly right, many folks don't like these threads cluttered with the long output of crash logs and the forum software can mangle them. They are often useless. I'm hoping that someone with more skill than me can help with the output.

I just figured that as I have no clue on how to use vi to reproduce this (and have always hated trying to learn vi over the years 🙂) that it would be good to see at least one log incase anyone from Apple is following along.

Maybe add one to http://pastebin.com/ if you want to avoid the page mangling

FYI secure keyboard entry is off by default.

Dec 16, 2016 12:39 PM in response to Drew Reece

Drew, secure keyboard entry is not currently enabled and I have never consciously used it any time.

I see two paths of interaction between Terminal and vi: Terminal is probably involved in relaying the keystrokes dispatched to it by the window system, and, as John mentioned but I had not previously considered, vi is doing something to cause Terminal to redraw the screen. Obviously these two things are closely coupled as redraws will occur only in response to keystrokes. I suspect redraws would be the more likely of the two to cause a problem, as I'm sure Apple reworks their window system graphics libs all the time.

Appended below is the first part of my crash info file. I have four of these saved and all four show the same stack backtrace with the only noticeable differences being memory addresses. It appears to be window system event dispatching code (DPSNextEvent) firing off a timer callback for some purpose. Looks like it's either waiting for input or for some response to a requested action, maybe, but that's pretty wild speculation. I can't tell if this is input side (keyboard) or output side (redraw) or something entirely different. Looking around on the web for posts on DPSNextEvent() I have encountered several backtraces that look similar up to the RunCurrentEventLoopInMode() call, so I would surmise this is pretty stock code for a lot of Apple GUI apps up to that point. I've done a lot of GUI programming with X/Motif/gtk but not any native Apple, so I'm way out of my depth here. If this is a new Sierra bug that's buried deep in Apple GUI libs it may be causing crashes in other apps, too, so maybe some other suffering users of unrelated apps out there will attract Apple's attention enough to fix it.

I will try to pay closer attention to my vi keystrokes to see if I can make this immediately reproducible and continue sending every crash report to Apple.

Here's my crash info:

Process: Terminal [845]

Path: /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

Identifier: com.apple.Terminal

Version: 2.7.1 (387)

Build Info: Terminal-387000000000000~3

Code Type: X86-64 (Native)

Parent Process: ??? [1]

Responsible: Terminal [845]

User ID: 1143

Date/Time: 2016-12-07 14:56:08.771 -1000

OS Version: Mac OS X 10.12.1 (16B2657)

Report Version: 12

Anonymous UUID: CB2977A1-9D44-4213-286F-C1BF1B930DF6

Time Awake Since Boot: 87000 seconds

System Integrity Protection: disabled

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

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11

Termination Reason: Namespace SIGNAL, Code 0xb

Terminating Process: exc handler [0]

VM Regions Near 0:

-->

__TEXT 000000010eeaf000-000000010ef7f000 [ 832K] r-x/rwx SM=COW /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

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

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

1 com.apple.Terminal 0x000000010eee7fc5 0x10eeaf000 + 233413

2 com.apple.Terminal 0x000000010ef45cc8 0x10eeaf000 + 617672

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

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

5 com.apple.Terminal 0x000000010ef53735 0x10eeaf000 + 673589

6 com.apple.Terminal 0x000000010ef1f159 0x10eeaf000 + 459097

7 com.apple.Terminal 0x000000010ef1f333 0x10eeaf000 + 459571

8 com.apple.Terminal 0x000000010ef25c94 0x10eeaf000 + 486548

9 com.apple.Foundation 0x00007fff88ca95df __NSFireTimer + 83

10 com.apple.CoreFoundation 0x00007fff87234d74 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20

11 com.apple.CoreFoundation 0x00007fff872349ff __CFRunLoopDoTimer + 1071

12 com.apple.CoreFoundation 0x00007fff8723455a __CFRunLoopDoTimers + 298

13 com.apple.CoreFoundation 0x00007fff8722bf81 __CFRunLoopRun + 2065

14 com.apple.CoreFoundation 0x00007fff8722b514 CFRunLoopRunSpecific + 420

15 com.apple.HIToolbox 0x00007fff867bc2ac RunCurrentEventLoopInMode + 240

16 com.apple.HIToolbox 0x00007fff867bc0e1 ReceiveNextEventCommon + 432

17 com.apple.HIToolbox 0x00007fff867bbf16 _BlockUntilNextEventMatchingListInModeWithFilter + 71

18 com.apple.AppKit 0x00007fff84dbe6cd _DPSNextEvent + 1093

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

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

21 com.apple.AppKit 0x00007fff84d7d983 NSApplicationMain + 1237

22 libdyld.dylib 0x00007fff9c493255 start + 1

Drew Reece

Level 6

10,666 points

Dec 16, 2016 12:54 PM in response to RogerDavis

RogerDavis wrote:

Drew, secure keyboard entry is not currently enabled and I have never consciously used it any time.

I'm suggesting enabling it may prevent the crashes. john henning has suggested it may be part of the OS that intercepts or potentially does some kind of 'data detection' to parse text.

Dec 16, 2016 1:16 PM in response to Drew Reece

Sorry Drew, I misunderstood. I will enable secure entry for a while and see if crashes continue.

Along the lines of thinking on unusual things about my sysconfig, I have disabled system integrity protection. What about you, John? Can't think why that would cause this sort of problem as the Terminal crashes have nothing to do with writing to a filesystem. Just grasping at straws as to why more people have not reported this behavior.

Terminal.app crashing: Can I disable callbacks?