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

Jul 22, 2017 3:50 PM in response to QuietMacFan

'screen' is just an example of what crashes the terminal app.

terminal is not rocket science - it should not crash - no matter what is running inside the terminal. Honestly - Apple's testing must be seriously second rate if a simple desktop app can be released with such serious problems.

Btw - you're obviously not a developer - the advantage of screen is that you can 'detach' it and come back to it later (while maintaining the application in the foreground).

Aug 20, 2017 12:23 PM in response to 123QAZWSX456

Improves the stability of Terminal app

... and perhaps it actually does! I have been trying unsuccessfully for the last 20 minutes to duplicate the crash as triggered by the crash recipe I posted here on March 31. I would be very interested to hear if anyone has any more vi- or screen-related Terminal crashes after doing the 10.12.6 update.

Nov 26, 2017 2:39 PM in response to RogerDavis

The 10.12.6 update is still crashing for me. The Terminal SIGSEGV is easily reproducible but not consistent though. This happens with vi but also without vi: I'm using a simple bash script that outputs ANSI escape color codes in an xterm-256 term the crash happens when it invokes another bash shell to run a command. My Terminal crashes frequently with this shell script that I wrote. So much so that I can't use it for my work. Very annoyed! Using an X11 xterm as a work around.

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

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

1 com.apple.Terminal 0x000000010e72cbb9 0x10e6f4000 + 232377

2 com.apple.Terminal 0x000000010e78ab88 0x10e6f4000 + 617352

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

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

Jul 28, 2017 1:34 AM in response to john henning

About the macOS Sierra 10.12.6 Update - Apple Support

"Improves the stability of Terminal app"

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

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.

john henning Author

Level 1

21 points

Dec 8, 2016 8:36 AM in response to Boyd Porter

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.

john henning Author

Level 1

21 points

Dec 8, 2016 3:21 PM in response to john henning

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

Barney-15E

Level 10

117,190 points

Dec 8, 2016 3:43 PM in response to john henning

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.

john henning Author

Level 1

21 points

Dec 8, 2016 4:12 PM in response to Barney-15E

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.

Barney-15E

Level 10

117,190 points

Dec 8, 2016 4:29 PM in response to john henning

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.

Drew Reece

Level 6

10,666 points

Dec 8, 2016 4:38 PM in response to john henning

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?

john henning Author

Level 1

21 points

Dec 8, 2016 4:51 PM in response to Barney-15E

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.

john henning Author

Level 1

21 points

Dec 8, 2016 4:56 PM in response to Drew Reece

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.

john henning Author

Level 1

21 points

Dec 8, 2016 7:19 PM in response to john henning

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

john henning Author

Level 1

21 points

Dec 8, 2016 8:41 PM in response to john henning

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.

Terminal.app crashing: Can I disable callbacks?