Terminal.app crashing: Can I disable callbacks?

Just installed 10.12.4 (hot off the presses) - and it seems to be fixed. Tested using the crashTerminal.applescript posted earlier in the thread.

I'm going to go back to my "regularly scheduled programming" - that is - normal usage, SSHed into remote Linux machine with screen and running /editing very long command lines. If I get any crashes from that I will post an update.

Thanks to everyone in this thread and their hard work narrowing this down and providing test scripts / hard data.

Hi gpolitis, does your stack backtrace look similar to the others posted here which were associated with the vi-triggered crashes? If you can supply a simple, reproducible example I will test on my system. If there is a remaining subset of Terminal redraw problems that are still causing crashes it will obviously be to the benefit of all here to get them fixed.

Well I just had Terminal crash again. I didn't think to save the trace, but I was SSH'ed into a Linux box using screen with a super long command line. So while the test case applescript doesn't seem to trigger it anymore, unfortunately I wouldn't call it fixed either.

@vom, That's unfortunate. Most of my crash cases are identical to yours -- ssh into a linux system, going to a screen session, and just up-arrowing (or sometimes up-arrowing then editing) a longer command line at some point in my session.

I just want to confirm that I'm experiencing exactly the same thing -- ssh into a linux system, going to a screen session, and just up-arrowing (or sometimes up-arrowing then editing) a longer command line at some point in my session.

If someone can give me a reproducible crash recipe using ssh/screen I will try to keep my Apple support case on this issue open. I am *not* a screen user, though, so I need some serious detail, i.e., every keystroke you can recall. I tried doing some screen experimentation myself a few weeks ago after reading others' reports on those crashes but could not make Terminal crash.

I think it's important to run this down to the bitter end, otherwise I'll be using vi in some different set of peculiar circumstances a few weeks/months from now and it will crash there, too.

Here's one in 10.12.3 (I'm waiting for the University to put out 10.12.4 in their Managed Updates).

Here's my sequence. I found that commenting out the crashy line still makes it crash so I could take out some work-specific info and make it not do anything, so here ya go.

1) Set up a terminal in Terminal.app preferences to "ssh {Some redhat system}, size 80x25 (don't know if that matters).

2) Open the terminal to the Red Hat system

3) screen -R myscreen # now you're in a screen session called "myscreen"

4) $ set -o emacs # allows you to edit a command line with emacs keys. Maybe vi-style editing works

# but I had this in emacs

4) Issue this sequence of 3 commands (first one is one long line; I separated the lines by a single blank line here but I had them one after the other:

#while true; do date>>/tmp/wget.log; wget --no-check-certificate --no-verbose --timeout=30 https://www.example.com 2>> /tmp/wget.log ; /bin/rm index.html*; sleep 30; done

view /tmp/wget.log

rm /tmp/wget.log

5) Up and down arrow through your command history to line #1, and try arrowing back and forth through it, maybe use CTRL+A to go to the start of the line (the way my screen is set, CTRL+A is an escape key so I have to issue CTRL+A CTRL+A, then CTRL+E to go to end of the line). Sometimes that will crash the line, other times it won't (like now as I'm typing this and trying it out, it's failing to crash after being reliably crashing the last few times I tried it and re-entered my screen session ... and now just after I said it failed, I did a single up-arrow to a command and it crashed). It seems to take a long line in your command history to crash it. *sigh* I wish this were as easy as the previous always-crash vi example.

6) If it crashes and restores things, re-login and go to "screen -r myscreen" to get back to it.

7) (for a non-screen user, just how to get out of this if you're experimenting) When you're done to destroy your screen, keep typing "exit" -- either it will finally say "screen is exiting," or you'll get a prompt to keep or destroy the screen and just press the right key to destroy it.

Breaking news -- I *think* it happens way more often after I've let the screen session sit for a few minutes. I had been trying to get it to crash again without success, and then I had left it alone for 5 minutes and up-arrowed past the long line. It briefly showed the line above it for a bare fraction of a second and crashed; I believe that's often the case.

(can't find a way to delete this, just edit -- I added the same info to my original reply. So ignore, redundant).

More now... I *think* it happens way more often if you leave it sit for a while. I was trying several times to crash it, and nothing, and just now I had it sitting for about 5 minutes, and up-arrowed past that long line and it briefly showed the line above it in the history and then crashed. I am starting to think I've seen that more commonly when I come back to something after a while.

Hi rkcarter, thanks for the example. Can you let me know after you have verified that this still causes a crash in the latest 10.12.4 Sierra? I will test on my system afterwards and forward the info to my Apple support contact if I can duplicate the failure.

Thanks!

I heard news the newest sierra found issues with the terminal crashing when (vt101?) escape sequences that were not handled were input. HOwever i'm unsure the news is not released by people who "manage viim for apple".

I THINK IT'S GREAT APPLE HAS MADE VI + TERMINAL.APP A PART OF IT'S MORE STABLE ITEMS IN IT'S RELEASES.

I'm glad your thing worked however: as I said before. Vim crashes in linux but Elvis does not. And it began doing so in the year 2007 or so and - not before. It's not xterm doing it either (the xterm the ncurses author wrote).

it's was never true (for GNU/linux) you can't crash terminal emulators with crazy sequences! what was true is that apps that fed garbage to "well known terminals like xterm" were banned from distribution or marked with warnings and not the default.

just try this: cat /usr/bin/bash >> /dev/tty1 and see if it doesn't crash even a text terminal, or cause bad problems with xterm.

the fact with vim is you cannot trust it. I beleive it was specifically hacked to send unsupported ESC sequences to terminals to cause either forced upgrade, dis-use of X-Windows, and etc.

there's ALLOT of malware and some of it is terribly "HIGH BROW". that doesn't mean there isn't simple errors in vim or Terminal.app that feed garbage or crash on input that was thought to be stable.

HOWEVER as i said. Vim since the 2000's has had a long list of bugs and complaints as to working with unix-like terminal support terminals. this likely began with international support + altered font support. the difference is that they (vim) broke what had been working and made the broken mode of operation the default mode of operation.

say all you want it's not malware. I know it is. for every Vim there are A THOUSAND MORE apps they have done this too. I'm swimming in the blame game excuses. I can hardly use my new PC without continual issues. the reason why: lack of accountability of who is putting in code in which OS (anonymous uploaders!!!). and high brow white collar crime.

Will do! I'm hoping they put 10.12.4 out tonight. I used to be able to grab updates separately but they seem to have found ways to cut that off. No worries, 3-4 more hours, and certainly by tomorrow night.

Still happening in 10.12.4. I think I have found another consideration to make it happen (change focus away from Terminal.app, wait 2+ minutes -- well, that's how long I waited, come back and start arrowing around). So to recap (and fix a slight typo -- if "screen" is using CTRL+A as its escape character, use CTRL+A A to go to start of line -- not CTRL+A CTRL+A):

Here's my sequence. I found that commenting out the crashy line still makes it crash so I could take out some work-specific info and make it not do anything, so here ya go.

1) Set up a terminal in Terminal.app preferences to "ssh {Some redhat system}, size 80x25 (don't know if that matters).

2) Open the terminal to the Red Hat system

3) screen -R myscreen # now you're in a screen session called "myscreen"

4) $ set -o emacs # allows you to edit a command line with emacs keys. Maybe vi-style editing works

# but I had this in emacs

4) Issue this sequence of 3 commands (first one is one long line; I separated the lines by a single blank line here but I had them one after the other:

#while true; do date>>/tmp/wget.log; wget --no-check-certificate --no-verbose --timeout=30 https://www.example.com 2>> /tmp/wget.log ; /bin/rm index.html*; sleep 30; done

view /tmp/wget.log

rm /tmp/wget.log

5) Up and down arrow through your command history to line #1, and try arrowing back and forth through it, maybe use CTRL+A to go to the start of the line (the way my screen is set, CTRL+A is an escape key so I have to issue CTRL+A A, then CTRL+E to go to end of the line). If you just got here and played with things, it may not crash. But hang on for the next two new steps:

NEW STEP 5a) Change focus to another app -- Chrome or Mail.app seem to work for this.

NEW STEP 5b) Return focus to Terminal.app and up-arrow through your command history. I think this is pretty reliable to crash it now.

6) If it crashes and tells you your terminal has been restored, re-login and go to "screen -r myscreen" to get back to it. Sometimes then going through the history will re-crash it quickly then.

7) (for a non-screen user, just how to get out of this if you're experimenting) When you're done to destroy your screen, keep typing "exit" -- either it will finally say "screen is exiting," or you'll get a prompt to keep or destroy the screen and just press the right key to destroy it.

When it crashes in 10.12.4, the part which looks like what others have posted here is:

8 com.apple.Terminal 0x000000010cde6c0c 0x10cd70000 + 486412

9 com.apple.Foundation 0x00007fffa1295f3f __NSFireTimer + 83

10 com.apple.CoreFoundation 0x00007fff9f80cd04 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20

11 com.apple.CoreFoundation 0x00007fff9f80c98f __CFRunLoopDoTimer + 1071

12 com.apple.CoreFoundation 0x00007fff9f80c4ea __CFRunLoopDoTimers + 298

13 com.apple.CoreFoundation 0x00007fff9f803c31 __CFRunLoopRun + 2065

Verified on my system rkcarter, thanks! (I also had to <CTRL>-Z and then 'bg' after entering the while-loop command line to return control to my ssh shell so I could enter the 'view' and 'rm' commands.)

The crash also occurs if I ssh into another Mac (ElCap), so the RedHat remote platform is irrelevant. When I ssh into another Mac your while loop generates a SIGSEGV fault of its own (within the loop, so it keeps running anyway), but no matter -- after I enter your 'view' and 'rm' commands and then up-/down-arrow for a bit, Terminal crashes.

I will try to keep the heat on with my support case contact using this example, thanks!

And, for all other followers of this thread, it would be very useful to know if anyone experiences any further vi-related crashes (as opposed to screen-related) in 10.12.4 or later. I wonder if Apple 'fixed' this bug by tweaking vi to stop sending whatever command sequence was making Terminal barf. If so, it's not a real fix if app X (as opposed to vi) continues to send the same sequence.

RogerDavis, sounds like you didn't catch that the "#" was a comment character in front of the 'while' command (running it was irrelevant -- coming across it with up arrows is relevant)... actually there could've been a "#" in front of all the commands I bet. It had started with a real command and I figured out that it was probably just the length of the command itself.