Terminal.app crashing: Can I disable callbacks?

I set Terminal --> Secure Keyboard Entry (checked "on") and have not had any crashes for a week or so.

But I just did, while in vim. In this time I'm pretty sure I know what my fingers were doing :-)

It was a local-to-my-laptop vim (MacVim 8.0) session, I had just yanked a line with 50 or 60 characters, scooted to location about a dozen lines away, and typed a command of ctrl-A to Append, and then two spaces followed by two ampersands. The crash seemed to occur on the second ampersand.

Why do no Apple engineers post to this thread? Surely they are suffering from this annoying crash just like the rest of us, and could save us all a lot of trouble by telling us what they know.

For example, "we've isolated and fixed the problem, and it'll be fixed in 10.12.3 (or whatever)".

Or, "we've narrowed it to x, y, or z. Please post examples if this-or-that".

I used to have a lot of loyalty to Sun Microsystems because they so openly helped customers solve problems. Engineers freely collaborated with customers, and while I'm sure they didn't show us all their dirty laundry, it was clear that they were sincerely trying to solve problems. Once, after we bought one of their first $650,000 data center servers, they even flew a team of kernel engineers and a compiler engineer to our Atlanta data center to try to capture a kernel panic using custom kernels. It took a few days, but they found the bug and fixed it. We were pretty **** loyal after that commitment! Apple, on the other hand, leaves us utterly in the dark even when everyone knows they have a bug. Maybe they'll fix it, or maybe they have an internal workaround and just don't give **** about us.

"Why do no Apple engineers post to this thread?"

Because Apple engineers would get inundated. Also, when I was an Apple engineer, I know we only had time to search these threads if we were looking for a repro case where we didn't already have one. Most of the time, that was fruitless. There is not enough information in this thread to build a repro case.

Essentially, this community a sandbox that is looked at (by engineering) less than 0.1% of the time. If that much.

As mentioned by a couple of other people, iTerm2 is a very usable replacement for Terminal.app. It takes care of all of my use-cases, at least.

Given that, yeah, there's no chance someone from Apple is going to read/care about this thread, I can heartily recommend iTerm2: https://www.iterm2.com/

Hi Baughn,

I'm trying to reproduce from your crash recipe, but no luck so far. I have never used either screen or irssi until today, so maybe I am doing something stupid. My hardware config is a bit different than yours, which may cause some obscure differences in the sleep/disconnect. I am using an iMac Sierra desktop (rather than a laptop) to connect to my remote server (also an iMac Sierra), as I do not have a Sierra laptop available. Here is exactly what I did:

(1) Configured client iMac to sleep after two minutes.

(2) Started Terminal on client, and using that Terminal window I ssh'd into server where I started screen (no arguments) and then, after screen started, started irssi (also no arguments) within the screen session. I then detached from screen with <CTRL>-a <CTRL>-d, and closed the ssh with a <CTRL>-d. (I did not engage in any activity whatsoever within irssi as I have no idea how to use it.)

(3) In the same original client Terminal window I reconnected to the server with ssh, and reattached to the screen session I started in the previous step with 'screen -r'. irssi was still running inside the screen session. Again, I typed nothing into the irssi program.

(4) I then walked away and allowed the system to go to sleep. When I returned, the client display was black, I moved the mouse to wake it up, and was shown the lockscreen password display. I logged back in, and then in the Terminal window I typed the up-arrow key (alone) followed by <RETURN>. I then saw the ssh disconnect message (but only after typing those two keystrokes).

I've tried this a few times, but alas no crash has resulted. Am I doing something wrong?

It would be very nice to be able to reliably reproduce this bug in a simple way. The only other suggested recipe which has been posted here involved tail'ing output from a specific web server engine that would be very difficult to replicate on another system, I think.

Thanks!

Roger

Essentially, this community a sandbox that is looked at (by engineering) less than 0.1% of the time. If that much.

Another good reason for everyone to click that 'Send to Apple' button in the crash dump notification. Deirdre, do you know what threshold is required for Apple engineers to notice THAT?

I am sort of wondering if this bug may not really be isolated to Terminal. The stack backtraces look like there's a dangling null pointer somewhere in Apple's GUI code, so it could be this affects other apps, too. Maybe if enough iTunes users complain all us influence-less Terminal jockeys will get some wholly unintended satisfaction. Here's hoping!

It has to be a top crasher, probably in the top 25 or 50. And yes, it is based on reports sent to Apple, because that's all they have access to.

Even if it is a null pointer issue, it could still be a bug that only Terminal is hitting.

If you do have specific repro steps that always work, even on a new account, then file a bug report with Apple with those specific steps. If nothing else, that'll make it easier to verify when the bug is fixed.

I have just started testing the old (El Capitan's) Terminal app with Case A of my last report(tmux>ssh>tail -f) and will report real soon if it also crashes or after a few hours if it does not. (4 minutes have past atm:-)

I could reproduce it too.

I tested your test_file both within tmux and bare terminal. In former case, after the crash, tmux does still maintains the last session. When I reattached to it, vim was there running sanely. I think this fact proves that tmux and vim are not the culprit.

I just (seemingly) had this happen to me ☹️.

I was ssh'ed into a Linux machine (Ubuntu 16.04) and running screen there. No idea what triggered it (I *wasn't* in an editor, but I did have a very long command line) - but it killed Terminal several times.

At first I though it might be Touchbar related. I just removed the 'man page' widget from the TB in Terminal. My thought was perhaps this is still getting parsed and processed - but reading through the thread it seems like there's plenty of folks without TB in the equation having this issue.

I'm really hoping this gets fixed in the next update. I've been Mac daily driver since 10.7 in 2011. I don't think I've ever had Terminal up and crash until today.

BTW, secure keyboard entry is now thoroughly debunked as a workaround based on ProValid's test (in case anyone still had the slightest doubt given other recent failures).

The test is interesting in its requirement of a peculiar combination of circumstances. If you first delete either the first or last line, it doesn't crash -- in fact, if you then undo those line deletions and try again with xxxx it STILL doesn't crash. Also, other ways of shortening the long line do not crash, e.g., deleting the last half by moving to the center of the line and typing D. Great detective work, ProValid!

Maybe if each of us can play around for 10 minutes a day for the next week and send all the crash dumps to Apple someone over there will wake up and smell the rancid coffee. (Deirdre, what's it take to be a Billboard Top-50 crash dump poster?)

summary: bugs take time. Patience, that is why we need workarounds

Good advice, John. (Although I can't help but note that half the verses of that song are the stereotypical blatant attempts at obfuscation of responsibility used by some tech support groups.)

Sun Microsystems was indeed an exceptional organization in its early days. I once sent Scott McNealy an e-mail when I had an issue with a local sales office concerning a single desktop workstation. He responded the same day and the problem was solved. I tried the same trick about 8 years later with Dell and you can imagine the (non-)result.

I have just filed my own bug report on this (100106033554) and cross-referenced it to John's (100085116387). I would have done this much earlier but my work systems were not under support and I only recently discovered that my kid's iMac at home (where I have only just now been able to recreate the crash) is still under AppleCare.

While speaking with Apple phone support I uploaded all crash dumps resident on my system directly into their case files (or so I was told) using Apple's Capture Data tool. I also made them aware of this discussion thread and the recent foolproof repros submitted there by ProValid and John.