Terminal.app crashing: Can I disable callbacks?

Chiming in that I'm seeing this problem as well & none of the updates are remedying the problem.

OS X is getting unfortunately cluttered to the extent that things as simple as Terminal are failing out...

I'm likewise seriously disappointed that Apple can't fix Terminal and several other irritating bugs. (another that has wasted a lot of my time lately is the mirroring of iPhone Messages onto MacOS: sometimes it just stops working)

So bite the bullet and switch to iTerm2.

It is a 100% cure. I resisted for weeks because of the time I'd have to spend just to get even with where I was in Terminal, but it is the only way out. (it took me several hours to get satisfactory syntax coloring everywhere)

Hi Randy,

I share your disappointment. Part of me wonders if this bug is not specific to Terminal only but rather has something to do with a more deeply buried part of their display rendering code based on the stack backtraces we've seen. It may be that, although we can reliably tickle this bug with Terminal, alteration of the offending code has ramifications for a lot of other software, hence the delay in a fix. (Just trying to give Apple the benefit of the doubt here with this speculation, which may have absolutely no basis in reality.)

I checked out iTerm2 and it certainly looks to have everything I would need, my only reluctance to jump ship has to do with my fear of typing all my super-duper top-sekrit passwords into a piece of unknown software. Terminal may well not be the least bit safer in that regard but at least I know where Apple lives. Plus, if I abandon Terminal I'll have nothing to complain about here.

Thanks to all who've continued to report their problems on this issue!

I too have bit the bullet and given up on Terminal. I've move over to iTerm2 and been happy. I really didn't want to as I do not like installing applications I don't find necessary, but since Apple has not fixed this in a reasonable time, I was forced to move on. Perhaps some day soon they will fix the issue, but until then, I'll be happy with iTerm2.

I am an Apple Enterprise Support customer; I have filed case# 100135749977 with Apple regarding these crashes. I have also provided them the other case numbers from these discussions.

I have provided the reproducible test cases, as well as EDC (Enterprise Data Capture) images showing the crashes on a freshly-built 10.12.2 Macbook which I then upgraded to 10.12.3 (both crashed).

Hopefully this will be solved soon, but Apple doesn't move very quickly, and it's likely too late to make it into 10.12.4 public release. :-/

-DDV

Wonderful, thank you!

By the way, I did try copying in Terminal.app from another machine with an older MacOS (10.10 Yosemite), and after brief testing it does seem to behave like Terminal should, and doesn't crash with my test case above, when running on my 10.12.3 OS.

Due to the confidentiality of Apple Alliance support requests, I can neither confirm nor deny that the fix will be part of 10.12.4, but might I suggest one look in an upcoming 10.12.4 beta to see if it happens to be fixed. 😉

For what it's worth, I've noticed that if I ssh into Fedora 25 or Ubuntu 16.04 hosts, even editing a command line with the built-in editor in bash can cause Terminal.app to crash... don't need to be in vi or vim for this to happen.

-Philip

I installed the beta on 2/25/17 and can confirm that the text and commands at the bottom of this post no longer crash vi. What crept in to break vi, or the terminal subsystem so dramatically. Was this bug always there?

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

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

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

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

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

To crash Terminal under 10.12.3: edit this file in vim and type: 3jdfo

Great to hear a solution is coming. I have been running 10.12.3 for weeks and run VIM on a Ubuntu 14.04 box vi a SSH constantly (with multiple Terminal windows) and have had no problems, until this morning and now have had 5 crashes of the Terminal App in about 90 minutes. I can find nothing that has changed so why I'm hitting this now is a bit perplexing.

iTerm2 is not a certain fix either. It seemed to be doing better, and then got a bus error.

Process: iTerm2 [4063]

Path: /private/var/folders/*/iTerm.app/Contents/MacOS/iTerm2

Identifier: com.googlecode.iterm2

Version: 3.0.14 (3.0.14)

Code Type: X86-64 (Native)

Parent Process: ??? [1]

Responsible: iTerm2 [4063]

User ID: 1602693331

Date/Time: 2017-02-27 12:20:05.549 -0800

OS Version: Mac OS X 10.12.3 (16D32)

Report Version: 12

Anonymous UUID: 0F9EB8AD-C38C-86DB-0E34-C7332DAD979B

Time Awake Since Boot: 14000 seconds

System Integrity Protection: enabled

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

Exception Type: EXC_BAD_ACCESS (SIGBUS)

Exception Codes: 0x000000000000000a, 0x0000000109280757

Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Bus error: 10

Termination Reason: Namespace SIGNAL, Code 0xa

Terminating Process: exc handler [0]

i deleted what i was going to say to be a little "quieter"

I also have vim continually crashing on me SEVERAL TIMES DAILY ... and suspect it's really Terminal.app and not vim

Booting to Safe Mode to use vim is absolutely not an option. The mere suggestion I hope was only for diagnosis. However the problem is already confirmed so that part of diagnosis is immaterial.

I think the excuses here for Apple are 0, ZERO. They flagged, it's an F, they need to pay to have it fix immediately and stop covering it up. They need to skip a trip to the Casino and get it done.

More data (I didn't read all 10 pages).

Repeat crash:

1. ssh to remote system

2. screen -ARd

3. ^r <- search history, for long command that wraps line

4. ^e <- jump to end of line

5. <esc> <bs> <- repeat to delete back word at a time

6. Line short enough not to wrap -> CRASH

Repeated same trial without screen -> No crash!

So I do think someone was onto it earlier when they mentioned the use of the alt screen by vim and screen. And clearly related to linewrap terminal codes.

*fingers crossed for a fix in 10.12.4*

Another +1 for this occurring very frequently, as it has for quite some time now.

The problem happens with both the original SysV-based vi as well as the newer vim. The remote OS has been Solaris based, Linux (debian and centos) based distros, and BSD based distros.

This is absolutely a problem with Terminal.app and has been happening for quite some time now.

It is sad that all instances of Terminal.app (IE: all windows) will crash as a result of a bug triggered in one instance.

Wow! Yes, that does it for me, exactly.

I can also often get it to crash *without* vim. I ssh into a machine, have a "screen" session on the remote system, and up arrow through some commands. If I try to edit one with a >80-character line, it will on occasion crash.