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

Barney-15E

Level 10

117,238 points

Dec 9, 2016 6:12 AM in response to john henning

Will see what happens with safe mode and new user.

Since you have tried Safe Mode already, just operate normally in the new user account.

Safe Mode prevents startup items from loading, so you are checking if there is something that loads at startup causing the problem.

With a new user account, you are checking to see if something that is in your user account is causing the problem.

Since it crashed in Safe Mode, the next step is to use a new account to see if you migrated something over to your user that is causing the crash. If the new account crashes, then it is likely some bug. I haven't yet seen vim crash, but I'm not actively using it, just have it running in the background.

john henning Author

Level 1

21 points

Dec 9, 2016 6:19 AM in response to Barney-15E

Thank you Barney! Safe mode is rather limited.

Switching now to new account in normal mode.

For what it is worth, three hours of work in the safe mode + new user account did not yield crashes. However, it should be noted that I didn't have any crashes working as my unsafe self yesterday, either, until things started getting busy around noon.

Meanwhile, I see that the 'truss' analog is called 'struss', but it won't dump the arguments to system calls; and that while dtrace is here (yay) it is mostly disabled http://internals.exposed/blog/dtrace-vs-sip.html

I turned on 'fs_usage', but won't bother digging through its voluminous output unless another crash occurs.

john henning Author

Level 1

21 points

Dec 9, 2016 7:56 AM in response to john henning

Summary: add Cisco VPN to list of suspects.

Details: Sometimes the most important variable is so large and obvious that you can't see it any more. It becomes part of the "background".

q. Does this system have any incompatible add-ons, extensions, privileged code poking its nose where it should not?

a. Well, I had a quiet morning (no crashes) both yesterday and today. What is it that makes a morning quiet and productive? Um . . . not yet being connected to internal work network.

Cisco 'AnyConnect' probably counts as a key and important kernel extension that I should have mentioned right off the bat. No proof that this is the problem, just admitting that I should have thought of it at the start as something important to consider.

Dec 9, 2016 9:28 AM in response to john henning

john henning wrote:

http://internals.exposed/blog/dtrace-vs-sip.html

Very informative link.

john henning Author

Level 1

21 points

Dec 14, 2016 6:35 AM in response to john henning

Context

When last we left off (prior to long weekend for me), clues were:

Compared call stack to non-crash: it did not seem abnormal
Crashes observed in safe mode
Crashes not seen with a few hours of new user account.

Suspects from last week

(1) Obsolete AnyConnect from Cisco

(2) Some ancient junk brought by Migration Assistant

(3) "A word becomes yellow; a box pops up above it; I don't recall asking for a web search, but is it trying to do one?"

I had originally called this 'deeper integration' of Terminal, thought it was new, thought it related to the callbacks
Barney explained that no, it is a feature that is not new (even if new to me)
The terminology in Trackpad Preferences is "Lookup & Data Detectors"

Update 1: Why were 'Lookup & Data Detectors' new to me?

On this year 2015 model, Lookup & Data Detectors were, indeed, enabled; and the method was "Force Click with one finger". The other (non-default) option is "Tap with 3 fingers"
This neatly explains why such boxes surprised me:
- On the old Mac, either it was disabled; or if enabled, I never happened to click with 3 fingers
- On the new Mac, it is easy to accidentally 'force click', especially for a new user of this particular type of trackpad.
- Thus: surprising, unexpected little definitions popping up.

Current status relative to the suspects

I am back in my original account
Changed: disabled suspect (3) 'Lookup & Data Detectors
Unchanged: suspects (1) and (2) remain in their obsolete junky state, for now.
So far, have not seen crashes; will update if I do.

john henning Author

Level 1

21 points

Dec 14, 2016 10:41 AM in response to john henning

Update: spoke too soon, just saw Terminal.app crash even with 'Lookup & data detectors' disabled.

Next test

Original account as Migration Assistant left it, except:
Changed: Suspect (1) Old AnyConnect: upgraded from 3.1.05170 to 4.1.06020
Changed: Suspect (3) 'Lookup & Data Detectors' - disabled.
Unchanged: suspect (2) remains in its junky state for now.

Drew Reece

Level 6

10,666 points

Dec 14, 2016 11:17 AM in response to john henning

Have you managed to crash it in the new user account yet?

john henning Author

Level 1

21 points

Dec 14, 2016 5:29 PM in response to Drew Reece

"have you managed to crash it in the new user account yet?"

No. Not yet.

Heading back there now.

Meanwhile, as to the original account, neither of today's 2 hypotheses were correct. Still got crashes after disabling lookup&data detectors; still got crashes after updating AnyConnect.

john henning Author

Level 1

21 points

Dec 15, 2016 7:17 AM in response to Drew Reece

"have you managed to crash it in the new user account yet?"

Yes.

Here are the 6 most recent, with notes about activity.

---------Yesterday----------------------- Terminal_2016-12-14-132746_hostname.crash Original account, trying to isolate Terminal_2016-12-14-170328_hostname.crash " " by turning features Terminal_2016-12-14-201951_hostname.crash " " off. No luck. ---------Switched to NewBareAccount------ NewBareAccount: 2 hours w/o crash yesterday evening. ---------Today--------------------------- Terminal_2016-12-15-061513_hostname.crash NewBareAccount Terminal_2016-12-15-064843_hostname.crash " -----------Rebooted at 6:51-------------- Terminal_2016-12-15-090621_hostname.crash NewBareAccount, at first careful to have no other apps up. The crash happened within 10 minutes after bringing up Safari.

All of today's crashes have one of the two signatures noted earlier. In all cases, the crash happened while I am within the application where I live most of my life, namely:

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

Drew Reece

Level 6

10,666 points

Dec 15, 2016 11:45 AM in response to john henning

I think the next step is to confirm it happens on a stock OS unless you can mange to work out what the crash log is showing. I'd try a new install setup on an external disk.

Do you have history of using vi on 10.11? That could be a potential workaround as you stated in the first post.

Are you sending the crash reports to Apple as they happen via the diagnostics & usage setting (in System Preferences > Security, Privacy tab)?

john henning Author

Level 1

21 points

Dec 15, 2016 12:29 PM in response to Drew Reece

Drew, thanks.

Yes, I have been using vim forever, including on 10.11

Yes, have been sending the crash reports; and have a case open with a senior support person, but he warned that the turnaround is unlikely to be fast.

Can you please clarify what you mean by 'stock OS'? Meaning ... install 10.12.1, install zero apps, and build slowly upward from there? Seems like a possibility.

Yes, giving up on Sierra does seem to be increasing a bit in its attractiveness. I did a brief test with an external disk, and El Capitan does boot. (Phew) I did not use it long enough to confirm stability.

Prior to either of the above somewhat heavy-weight solutions, I still wish I could get a better sense of exactly what is happening on the system at the time - at any level.

System Services tracing - Running dtrace has barriers, so it is hard or impossible to peek at the system calls.
I/O tracing - For a while I was tracing file activity (fs_usage); maybe I should try that again
Vim tracing - I can build a copy of vim from source, with symbols enabled, and peek inside it; but it is not the editor that is crashing. It is terminal.app.
Human tracing - The crashes do not *appear* to relate to any particular move that I have recently made in the editor, but it is entirely possible that I am simply not conscious of what I am doing sufficiently to be aware - my fingers know how to type, I don't. With that I ask, is there some friendly (hah!) keystroke logging I could turn on that might help me realize that "oh.... it happens only when I am reaching for the mumble key and must accidentally be hitting the fritz function key."
Processes - I doubt I can trace all process birth and death, but I do at least have SOME data from plain old 'ps -ef'. I will try to trim it down small enough to fit here.

Drew Reece

Level 6

10,666 points

Dec 15, 2016 1:36 PM in response to john henning

By stock OS I mean only install 10.12 & it's updates.

Do not even setup iCloud as it may sync settings for apps depending on what features you use.

If vi does the same thing there you can start to assume the vi build is broken on this OS.

Then slowly install the apps that you need & retest… slow & may be unproductive.

I'm afraid you may know more about the process tracing & profiling than me. I don't have much development experience, mostly troubleshooting & poking at things until they work 🙂

If your other apps have suitable data for use on 10.11 I'd go back to that for a quick fix.

Otherwise you could try other Terminal apps to see if they behave differently to the built in one. You may find many via…

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

john henning Author

Level 1

21 points

Dec 15, 2016 1:54 PM in response to john henning

"I do at least have SOME data from plain old 'ps -ef'. I will try to trim it down small enough to fit here"

This is trimmed by 80% from ps -ef just after the latest crash of Terminal.app The output is divided into three groups:

I. Processes that started at boot time
II. Proceses that that started later, and which are not associated with a TTY
III. TTY-associated (user) processes

For readabilty, leading zeros are trimmed

Observations and questions

Everything that gets started at boot time, except Cisco AnyConnect, lives in directories that look like system directories. q. How much confidence, if any, should the directories of origin give me?
It looks like I started Safari about 6 or 8 minutes before the crash of Terminal. Do any of the processes from around 9:00 AM look abnormal?

I. Processes that started at boot time. All in this section had a start time of 6:52 or 6:53AM.

# processes Directory string from start of CMD 3 /System/Library/ 56 /usr/libexec/ 23 /usr/sbin/ 37 /System/Library/CoreServices/ 20 /System/Library/Frameworks/ 4 /System/Library/Frameworks/Security.framework/Versions/A/ 57 /System/Library/PrivateFrameworks Plus: TIME CMD 1.75 /opt/cisco/anyconnect/bin/vpnagentd -execv_instance 10.93 /sbin/launchd .09 aslmanager .02 autofsd .33 sysmond TIME = number of CPU seconds, from 'ps -ef' CMD = command

II. Proceses that started later, and which are not associated with a TTY

STIME = start time TIME = CPU time To control horizontal width, in this section (which is sorted by STIME) ..SLPF.. == /System/Library/PrivateFrameworks ..SLF.. == /System/Library/Frameworks ..SF.. == /System/Library STIME TIME CMD 6:56 .01 ..SLF..AudioToolbox.framework/XPCServices/com.apple.audio.Sandbox Helper.xpc/Contents/MacOS/com.apple.audio.SandboxHelper 6:57 .01 ..SLPF..InstallerDiagnostics.framework/Versions/A/Resources/ installerdiagd 6:57 .40 ..SLPF..CoreSuggestions.framework/Versions/A/Support/suggestd 7:30 .01 /usr/sbin/cfprefsd agent 7:30 .06 /usr/libexec/lsd 7:30 .08 /usr/libexec/trustd --agent 7:30 .01 /usr/sbin/distnoted agent 7:52 .01 /usr/libexec/taskgated -s 8:42 .04 ..SLF..CoreServices.framework/Frameworks/Metadata.framework/ Versions/A/Support/mdworker -s mdworker -c MDSImporter Worker -m com.apple.mdworker.shared 8:57 .03 /usr/sbin/ocspd 8:59 .06 ..SLF..QuickLook.framework/Resources/quicklookd.app/Contents/ MacOS/quicklookd 8:59 3.35 /Applications/Safari.app/Contents/MacOS/Safari 8:59 .06 ..SF..CoreServices/CoreServicesUIAgent.app/Contents/MacOS/Core ServicesUIAgent 8:59 .49 ..SLF..WebKit.framework/Versions/A/XPCServices/com.apple.WebKit. Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking 8:59 .29 ..SLPF..SafariShared.framework/Versions/A/XPCServices/com. apple.Safari.SearchHelper.xpc/Contents/MacOS/com.apple. Safari.SearchHelper 9:00 .33 ..SLPF..SafariSafeBrowsing.framework/com.apple.Safari.Safe Browsing.Service 9:00 1.97 ..SLF..WebKit.framework/Versions/A/XPCServices/com.apple.WebKit. WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent 9:00 .20 ..SLF..Metal.framework/Versions/A/XPCServices/MTLCompilerService .xpc/Contents/MacOS/MTLCompilerService 9:00 .01 ..SLF..MediaAccessibility.framework/Versions/A/XPCServices/com. apple.accessibility.mediaaccessibilityd.xpc/Contents/ MacOS/com.apple.accessibility.mediaaccessibilityd 9:00 .03 ..SLPF..SafariShared.framework/Versions/A/XPCServices/com.apple. Safari.ImageDecoder.xpc/Contents/MacOS/com.apple.Safari. ImageDecoder 9:00 .24 ..SF..Services/AppleSpell.service/Contents/MacOS/ AppleSpell -psn_0_208947 9:06 .10 ..SF..CoreServices/SubmitDiagInfo server-init 9:06 2.59 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal 9:06 .04 ..SLF..CoreServices.framework/Frameworks/Metadata.framework/ Versions/A/Support/mdworker -s mdworker -c MDSImporter Worker -m com.apple.mdworker.shared

Note just above that 'SubmitDiagInfo' started about the same time as the crash recorded in Terminal_2016-12-15-090621_hostname.crash

III. TTY-associated (user) processes

Everything above this point had TTY '??'. The ones below differed:

STIME TTY TIME 9:06 ttys000 .01 login -pfl newbareaccount /bin/bash -c exec -la bash /bin/bash 9:06 ttys000 .01 -bash 9:06 ttys001 .01 login -pfl newbareaccount /bin/bash -c exec -la bash /bin/bash 9:06 ttys001 .02 -bash 9:07 ttys001 .00 ps -ef 9:06 ttys002 .01 login -pfl newbareaccount /bin/bash -c exec -la bash /bin/bash 9:06 ttys002 .01 -bash 9:06 ttys003 .01 login -pf newbareaccount 9:06 ttys003 .01 -bash

Dec 15, 2016 7:24 PM in response to john henning

Hi John,

I am having this exact same problem, and posted to this group several hours ago with no reply.

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.

My system was recently upgraded from ElCap, the crashes started happening immediately after that. (I did an upgrade from the App Store, not a full wipe and clean install.) My own work environment has not changed at all since I was running under ElCap and having no Terminal crashes, so I would guess that my personal environment is not the issue (and neither is yours, likely). One thing which does make my environment different from many other users, however, is that I use FocusFollowsMouse and not ClickToType:

% defaults write com.apple.Terminal FocusFollowsMouse -string YES

Tomorrow I may experiment with ClickToType, although I was using FocusFollowsMouse under ElCap and having no trouble. Which focus mode are you using? If FFM then maybe that's the source of the bug, if CTT then not.

Thanks!

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

Hi John,

Another oddity of my personal environment (and evidence of advanced decrepitude): my command shell is tcsh, not bash -- so, I've got Terminal running tcsh running vi, and using FocusFollowsMouse with a half-dozen Terminal windows open.

Roger

Terminal.app crashing: Can I disable callbacks?