Terminal.app crashing: Can I disable callbacks?

Hi rkcarter, I did see the # but thought it was part of your terminal prompt. No worries!

Experimenting a bit more today, I have found that (1) the ssh is not necessary, nor the 'set -o emacs', (2) the long command can be pretty much any bit of gibberish that wraps a couple of lines, and (3) the following 'view' command DOES seem to be important. I can't make the crash happen if I substitute any other command in that spot -- probably the full screen redraw that occurs when view (i.e., vim) starts up is critical to triggering the crash?

That's fascinating! And today I've been having trouble reliably recreating it; I had just run OnyX and cleared all my caches and rebooted; for a bit I thought it had fixed it, but going back and forth between doing actual work and occasionally flipping over to the terminal window it did crash. I did bring up "view {somefile}" and quit it once or twice in there. I hope we can get something that the tech can reliably make happen.

Hi all,

I think I have distilled the screen-triggered crash recipe shared here by rkcarter to the bare minimum necessary. It will run on a standalone Mac desktop without requiring ssh, and crashes very reliably for me even under the new 10.12.4 release that seems to withstand ProValid's vi-triggered crash recipe. Thanks again rkcarter for providing the starting point on this!

(1) Log in to a clean, empty desktop with nothing running (i.e., no open windows of any kind on the desktop) under a userID running the bash login shell. Start Terminal, opening a single 80-character-wide window. Do not open any other windows in Terminal, and do not open any other applications or otherwise do anything to take keyboard focus out of that one Terminal window, within which you should perform all of the following actions.

(2) Run the screen command (no command options needed) at the first bash prompt in the Terminal window:

$ screen

If you see a welcome message, just hit <RETURN> to make it go away and return you to the next bash prompt.

(3) At the second bash prompt, type any gibberish command of your choice, as long as it wraps at least two lines, i.e., is longer than about 180 characters and contains no <RETURN> characters. Use any alphabetic characters and <SPACE> to create a couple dozen words in the command:

$ jsdhf fgh sf jhsgf jhsdgf jshf jshfg jsdhfg sjdhfg sjdhfg sjdhfg sjhdfg sjhfg sdjhfg sjdhfg sjdhfg sjdhfg sjhfg sdjhfg sjdhfg sjdhfg sjhdgf jshdfg sjhdfg jsdhgf jsdfjsdhgf jshdgf jsdhgf jsdhgfsjedhfg

-bash: jsdhf: command not found

(4) Start view (i.e., vim) on a non-existent file:

$ view /tmp/xx

view will redraw the window, after it does just type the two characters

:q

(that's a colon and a small-q) followed by <RETURN> to exit the program and get the next shell prompt.

(5) Type the following command, which will fail:

$ rm /tmp/xx

rm: /tmp/xx: No such file or directory

(6) Now type the up-arrow key a few times. Terminal will very likely crash as soon as bash tries to redisplay your long-line gibberish command. Sometimes you may need to up-arrow past that command, then down-arrow a few times, etc., to cause the crash.

It does seem important that you run both the 'view' and 'rm' commands above. I suspect that the 'view' command is necessary because it triggers a full window redraw. I have no idea what purpose is served by the subsequent 'rm' command, but it does appear to be necessary to trigger the crash.

Thanks @RogerDavis ! I was able to reproduce the error using your instruction multiple times. I noticed that typing up-arrow key has to be have some interval (e.g. 1 second) to reliably reproduce the error.

Glad to hear (well, sort of ;-> ) that this fails for you, too, brucedarkspoon. I never use screen myself, but am a heavy vi user and do not believe for one second that whatever workaround Apple implemented in 10.12.4 that patched ProValid's vi-based test case has truly fixed the problem. Terminal is still crashing due to redraws of long lines and I bet there are all kinds of ways vi can still tickle a failure path.

I am getting absolutely nowhere with the support case #100106033554 which I filed. Almost one month ago I pinged my case representative for a progress report. It took him a week to write back to me, and all he could tell me was that he was trying to find out what was happening with the fix. I have pinged him every week since then and I continue to get exactly the same answer -- he is still trying to find out what's going on. Apparently Apple only makes and sells phones, but does not use them internally (nor e-mail) to communicate useful information between their support and engineering staffs. I will keep trying.

John Henning, have you had any better luck in getting anything useful out of your case rep?

Hi all,

Here is the latest from my case rep:

I received an update on the ticket that I created for you. It appears that

the last OS update was designed to address an issue that was considered

similar to yours. We have been able to successfully replicate your issue and

the information has been sent to our engineering group to develop a proper

resolution. Once again, I ask that you keep your computer up to date and I

will keep you posted as additional details become available.

As I recall we had to wait through at least two 10.12.x updates to get a patch that invalidated ProValid's test case. I wouldn't expect Apple to do much better with fixing this latest reproducible case either.

No, 10.12.5 has NOT fixed the terminal.app crashing issue. I upgraded yesterday, booted terminal, signed in, started screen, hit up arrow couple times, down arrow once, terminal crashed w/same error it had before!

I can also confirm that the latest screen-based crash recipe posted above still causes Terminal to crash under 10.12.5. Frustrating as ever, and very disappointing that Apple just doesn't seem particularly interested in fixing this.

"Me too" - confirming what others have said - this is still happening in 10.12.5. The remote linux system where I issue the commands that trigger it - I hadn't had an issue since 10.12.15 was officially released. So I let my guard down and started connecting to that machine in Terminal. Just had a crash, while editing a very long command line.

My personal workaround for the time being - is using XQuartz and good old xterm. Man oh man I wish Apple would take this serious and fix it. It doesn't seem like much to ask.

It doesn't seem like much to ask.

Indeed not! In 30 years of professional work on many platforms I've never seen a terminal application behave this badly. Guess this technology is harder than it used to be.

Adding another voice to this - Happening to me on a macbook air that I just upgraded to Sierra. Looking for a way to back out the upgrade without doing a full reinstall.

My sincere advice to users of apple products in general - If you like the way it works now, DO NOT UPGRADE ANYTHING!

Just had another crash, but this time using "less". Had a huge log file from an unrelated issue I'm troubleshooting, and was quickly jumping pages up and down at a time looking for timestamps (it was a VERY verbose log). I noticed less got sluggish, delayed, and then *poof* 😟 Terminal crash.

Does anyone have an Applescript to reproduce this - that crashes on 10.12.5 (or greater) ? I'd love to test this out - but I personally had trouble following one of the most recent "manual" instruction lists to reproduce.

It was reported that Sierra 10.2.x fixed a bug most complained of that vi(1) was crashing Terminal.app

It was found those not using Sierra 10.2.x can use elvis(1) instead, which is very stable - and can be found on sourceforge ready to compile for apple.

> "User impact

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

User impact of what? People responding here are not stating a clear instance of a repeatable problem.

------------------------

nvi(1) was a specific complaint found elsewhere in Communities, vi was crashing if one joined lines. Don't go back to El Capitan for Terminal - Sierra 10.1 has the known bug nvi(1) crashes Terminal - which 10.2 fixed.

Note that nvi also crashed Linux xterm and some including me say "it was designed to", because it forced people not to use xterm and use a (debian) made replacement built upon the copylefted code (one more reason i'm on an apple not an ubuntu pc, thank goodness).

I haven't heard any application crashing Terminal other than nvi(1). I used elvis(1) on versions that had the issue and elvis(1) works perfect - no crashes.

------------------------

screen(1) no, just open more terminal tabs.

screen(1) has been a huge source of "bug reports" in Linux and FreeBSD for many years. Saying Apple has a bug because screen isn't working is not appropriate.

As far as screen(1), screen has many bugs and is very old software for a special purpose, with many known bugs, difficult to make use of. It has a use but you are very unlikely to match that use up with anything your doing on today's computers. Avoid it.

The problem is people are trying to use screen in environments it was not designed to work in. (Your not attaching using serial negotiation tty, your not using a PC where a DEC VT100 had been sitting using early Unix.) In this case your using a wide character "internationally enabled / hacked" Terminal emulator, which is not the unix environment screen(1) had been used with.

Do you really need to "multiplex" terminals? Why not just open more terminal tabs? or maybe use xterm (if terminal cannot be configured, compiliing xterm and configuring likely CAN achieve the correct environment, if set up properly, only if set up). Also according to your statement you are using Terminal to ssh to Linux, and screen(1) is running on Linux not Apple: with that said, screen may not be the culprit because the (liability) is layered - it could be a crash from a linux bin that transmitts the wrong chars to apple.

OFF-TOPIC

A little background on Xterm312 mentioned above. Curses was a BSD terminal emulation lib (never finished), (mark and tom) made nCurses to finish Curses, and then Xterm. Xterm supports a wide number of platforms (this does not help an Apple end user), including OS/X (not Sierra per say), and supports Tektronics (oscilliscope maker / military scope) vector graphics using 'terminals'. a quip from one Unix guru: "if i only had time to explain to people the many things terminals used to be able to that can't now do" (for example: direct control of the CPU)

X.org server is Not XEROX X-Windows compatible: X.org is designed to copy-left code but destroy any app that works with X-Windows, compatibility wise, and favor (non-usa) video cards, foreign control of code submitted, etc. Your not using X when you use X.org: it's the anti-thesis of Xfree86.

Sierra is not X or x.org anymore (says Apple, I've not verified that). My bets are that's the best thing for Apple users whether they are using the GUI or the BSD userland. X 'maintained' by hostile or (competitor) parties only becomes a forced upgrade or ransom-ware issue.

Apple should likely stop using mozilla and apache2 as well, review code they are using, and go from there adding only what code benefits apple users. I notice that Apple doesn't use the newest versions of FreeBSD utils and hopefully the reason why is careful checking of "what works" and careful removing of (malware / buggy "new" features).