690      iPhone_iPad_Mac_apple

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.

Try bothSafe Mode and create a new test admin account. Work in one and then the other. Safe Mode will eliminate the possibility of third party kernel extensions, and the test account will tell you whether there is something wrong with your current login. Does the Terminal still crash?

Have a nice day.

Boyd, thank you for the reply, yes these are 'on the list' of things to try.

Still hoping that a kind reader can answer the primary question: is there a setting somewhere to disable the timer callbacks feature?

I should add that I have also opened an inquiry with support, who are researching it.  The very polite and very interested support representative promised to follow up with engineering; he also encouraged me to continue research via the web.  Unfortunately, my searches for

how-to-edit Terminal settings 

keep turning up

how-to-use-Terminal to edit settings of OTHER apps. 

Thus I decided to ask here.

A bit more data.  Now up to 8 crashes.  I think that during all 8, I was in the primary application in which I live my life: vim  (aka /usr/bin/vi).  I do not recall any particular pattern to what vi command I was doing.  I am running the stock version included with the system (7.4.898).

It seems that crashes did not occur during the quiet part of the day before I brought up a web browser and email.

Question.  Does a 'callback' have anything to do with the now-apparently-deeper integration between Terminal and other apps?  I thought it did, which is why I asked whether it could be disabled, but perhaps that was barking up the wrong tree.

Looking over the 8 crashes, it seems that there are 2 basic signatures (various detail removed for the sake of brevity)

   signature 1                      signature 2

                                | platform_memmove$VARIANT$Haswell
                                | 0x10f7f7000 + 233413
                                | 0x10f7f7000 + 617672
CFStringCreateImmutableFunnel3  | doubleClickAtIndex:inRange:
CFStringCreateWithCharacters    | URLAtIndex:effectiveRange:
stringWithCharacters:length:    | Terminal  0x10f7f7000 + 673589
Terminal 0x1003e3000 + 245524   | Terminal  0x10f7f7000 + 459097
Terminal 0x1003e3000 + 459976   | Terminal  0x10f7f7000 + 459571
Terminal 0x1003e3000 + 486548   | Terminal  0x10f7f7000 + 486548
----------------------------------------------------------------
common beyond this point
----------------------------------------------------------------
   NSFireTimer 
   CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ 
   CFRunLoopDoTimer 
   CFRunLoopDoTimers
   CFRunLoopRun
   CFRunLoopRunSpecific 
   RunCurrentEventLoopInMode
   ReceiveNextEventCommon 
   _BlockUntilNextEventMatchingListInModeWithFilter 
   _DPSNextEvent
   nextEventMatchingEventMask:untilDate:inMode:dequeue:
   NSApplication run
   NSApplicationMain
   start

What is the "deeper integration" you speak of? That may give us a hint on what to look for or maybe things to try to trigger it.

I ran vim and poked through the help files, but didn't spend more than a few minutes in it and no crashes.

I'll leave it sitting in Terminal for a while to see what happens.

What was migrated from your other Mac? Various system mods do not work in Sierra where they did work in El Capitan.

Thank you for the reply Barney. 

I don't know whether the seeming 'deeper integration' has anything to do with it, although that was my original hypothesis.  What i mean by the term is that every now and then, for reasons that are not yet apparent to me, the GUI appears to be offering to go out to the web and look things up for me, even though I thought I was not interacting with a GUI at all at that instant.  I thought I was just typing along in a plain old vt100 emulator (well, xterm).  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?

As pointed out by Boyd, and as acknowledged in my very first note, I really do need to trundle over to safe mode, or a new account, because the correct answer to your other question is: "I do not know" what Migration Assistant brought over.   Sigh.  The only things I can think of that might count as 'system mods' are that I had installed smcFanControl, and used it about 3 times in the last year (none since moving to the new Mac); and I can see in System Preferences that apparently it remembers that I had installed SwitchResX approximately two or three Macintoshes ago.  I cannot remember the last time I awakened it; maybe 5 years?

Coming back to one of my 'secondary questions' from the original note - can I run the "old" terminal.app from a previous version of Mac OS X under Sierra, to see if that is stable?   I suppose I could just go try copying it from one of my backups /Applications folder (to a temporary folder under my login, not the system directory) and see what happens.

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?

That feature has existed for the last few OS's. It provides a dictionary lookup of the selected word. You can activate it by three-finger tap on any word. The three-finger tap is configurable in the Trackpad System Prefs.

It is a Service that can be selected from the Services menu, and you can create a shortcut for it, but there isn't one set by default.

I have no idea if the old app will work. It would just be a matter of dragging the app over from the older Mac.

I'm just wondering if it is not really a problem with Terminal, but something else you have installed. I don't have any Terminal crashes. It is open all the time, but I'm not working in it all the time. Also, I don't use vim, so it may be difficult for me to rule out (or in) that the problem is Terminal itself.

The crash does mention the Haswell processor which I do not have, so that may also have something to do with it.

I also don't know if you could install El Capitan on that Mac. You mentioned it was exact same as your old one, so it might be possible to install El Capitan, but normally you cannot install an OS previous to the one it shipped with. The exception would be your case where the two are identical and the original model shipped with the earlier OS.

Other options you may consider is iTerm2 or xTerm (requires XQuartz).

I'm not a big fan of things like SMCFanControl, and I don't know what SwitchResX does, but if it is that old and installed, it may be a source of some other problems if not this one.

Can you stop thinking about what might or might not be the problem & get on with doing the safe mode & new user account test?

It's good to imagine what could cause a problem but it is far more productive to isolate the issue to certain areas of the OS via the process of elimination.

It could be a dot file in your user account that configures vim or any of the other settings that Migration Assistant moves over.

john henning wrote:

Coming back to one of my 'secondary questions' from the original note - can I run the "old" terminal.app from a previous version of Mac OS X under Sierra, to see if that is stable?   I suppose I could just go try copying it from one of my backups /Applications folder (to a temporary folder under my login, not the system directory) and see what happens.

Just try it if you think that will help anything, you don't seem willing to follow the sound troubleshooting advice already suggested here so why not just throw any old version of Terminal on the OS & see what happens?

OK, the pop-up was new to me but not new to Mac.  I don't know why I never stumbled over it before.  Maybe a default preference changed.

Thank you for the mention of other terminal emulators.  Will research.

My old Mac had El Capitan.  My new Mac is the mid-2015 Retina 15", brand new 6 days ago (intentionally bought older model from remaining in-stock-new-items at B&H Photo); to my surprise, it shipped with Sierra; however, assuming that it will run any OS that was supported in mid-2015, perhaps I could wipe the internal disk and start over using my handy USB key with El Capitan or even my USB key with Yosemite.

Yeah, I am not really a fan of SMCFanControl either; the rare occasion when I used it was just to see if it could help me use my ears to figure out which fan was whining more than which.

Yes, I noticed the mention of Haswell too; however I presume that to be innocent, and the fault to lie higher up the call stack

Sidebar: it is likely similar in spirit to processor specific library routines on other Unix systems, commonly found for 20+ years: when moving memory from here to there, the best way to do it varies from one hardware architecture to another, and you do it a LOT, and therefore the performance matters a lot.  Therefore you never want to execute things like 'give me 10 pages that have been zeroed' or 'move these 1024 bytes' using code that was compiled in a generic manner; instead, the decision of just exactly how to do that is left to the very last instant, in a low-level routine which may well be written in assembly, with just the right tweaks for pre-fetching (it is amazing how many variations there are for prefetch instructions) and for operand sizing to make efficient use of busses and caches.

Drew the trouble shooting advice is sound and appreciated.  It is also a matter of scheduling it into other activities.  Thank you for the reminder.  

What is normal?A problem with the posted call stacks is that not knowing what is 'normal', it is hard to tell what is 'abnormal'.  Therefore I have been playing with the 'sample' utility and have learned that the crash stacks posted earlier do not look absurdly different from stacks while running.

For example, on the left is a stack from a running, NOT crashed, safe mode (yes, safe mode :-) Terminal. 

It is excerpted from much longer output, and once again much detail (such as most address strings) has been removed.  On the right is one of the crashes.  (The decimal addresses posted earlier were translated to hex, so we can compare them)

The presence of the memmoveHaswell on the top might raise again the question of whether it is to 'blame', but I don't think so.  Recall from the very start of this discussion that the immediate cause of the SEGV is that something has attempted to use an address consisting of nothing but zeroes.  I don't think memmove invented that address by itself.

Bottom line: the crash stack probably won't teach us much, except perhaps to suggest that it might be useful if there is a way to instrument all the calls to, say, URLAtIndex or doubleClickAtIndex.

Running copy                       Crash
Terminal 0x104728000 + 0x198e9                                         
Terminal 0x104728000 + 0x324ca                                        
Terminal 0x104728000 + 0x198e9                                        
Terminal 0x104728000 + 0x19624     platform_memmove$VARIANT$Haswell
Terminal 0x104728000 + 0x38f25     0x10f7f7000 + 38FC5
Terminal 0x104728000 + 0x96cc8     0x10f7f7000 + 96CC8
doubleClickAtIndex:inRange         doubleClickAtIndex:inRange:           
URLAtIndex:effectiveRange          URLAtIndex:effectiveRange:            
Terminal 0x104728000 + 0xa4735     Terminal  0x10f7f7000 + A4735
Terminal 0x104728000 + 0x70159     Terminal  0x10f7f7000 + 70159
Terminal 0x104728000 + 0x70333     Terminal  0x10f7f7000 + 70333
Terminal 0x104728000 + 0x76c94     Terminal  0x10f7f7000 + 76C94
NSFireTimer                        NSFireTimer 
CFRUNLOOP_IS_CALLING_OUT_TO_A_     CFRUNLOOP_IS_CALLING_OUT_TO_A_
       TIMER_CALLBACK_FUNCTION            TIMER_CALLBACK_FUNCTION
CFRunLoopDoTimer                   CFRunLoopDoTimer 
CFRunLoopDoTimers                  CFRunLoopDoTimers
CFRunLoopRun                       CFRunLoopRun
CFRunLoopRunSpecific               CFRunLoopRunSpecific 
RunCurrentEventLoopInMode          RunCurrentEventLoopInMode
ReceiveNextEventCommon             ReceiveNextEventCommon 
BlockUntilNextEventMatchingList    BlockUntilNextEventMatchingList
               InModeWithFilter                   InModeWithFilter 
DPSNextEvent                       DPSNextEvent
nextEventMatchingEventMask:unti    nextEventMatchingEventMask:unti
          lDate:inMode:dequeue:              lDate:inMode:dequeue: 
NSApplication run                  NSApplication run
NSApplicationMain                  NSApplicationMain
start                              start

While I was composing the previous update (using vim in Terminal), running as myself in Safe Mode, there 3x more crashes of Terminal.   Nothing new from the call stacks.

Will see what happens with safe mode and new user. 

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.

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  https://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.

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. 

最后更新：2017-08-21 04:18:10

  上一篇： Hibernation bug (?) in macOS Sierra 10.12.6

  下一篇： Printer problem