iTerm Build 2.9.20150531-nightly crashes when using aText macros and large buffer
OS Version: 10.10.3 iTerm Version: Build 2.9.20150531-nightly aText Version: 2.17
I have used aText macros in iTerm for several years now without issues, including those same macros causing crashes today.
Steps to reproduce:
- Open iTerm, ssh to some host (I was logged into a CentOS 6 box for my reproduction of this bug)
- Fill the term buffer somewhat (I did this by cat'ing a large log file)
- Attempt to use an aText macro within the same term -- as aText pastes the macro into the buffer, iTerm app crashes completely.
My hypothesis is this possibly something to do with https://github.com/gnachman/iTerm2/commit/dc6d204beaeb1222f6448364b054fbb041f87e55 as I have updated to the latest nightly build fairly often and have not had this issue before. I was last running Build 2.9.20150519-nightly without issue. I'm going to try downgrading to Build 2.9.20150530-nightly to see if the same behavior occurs.
By the way, thank you so much for all your work on iTerm 2 -- this app is literally why I use a Mac and is critical to about 90% of what I do every day for work. :-)
Debug log and plist file attached. com.googlecode.iterm2.plist iTerm-debuglog-20150531.txt
Activity
I also noticed this in the crashlog:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Application Specific Information: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Failed to get CharCodes from EventRef (-9870)' abort() called terminating with uncaught exception of type NSException Application Specific Backtrace 1: 0 CoreFoundation 0x000000010ac4203c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x000000010a8be76e objc_exception_throw + 43 2 CoreFoundation 0x000000010ac41eed +[NSException raise:format:] + 205 3 AppKit 0x00000001090b8264 -[NSEvent _matchesKeyEquivalent:modifierMask:] + 305 4 AppKit 0x00000001090b8021 -[NSButton performKeyEquivalent:] + 179 5 AppKit 0x00000001090b7d47 -[NSView _performKeyEquivalent:conditionally:] + 189 6 AppKit 0x00000001090b7f48 -[NSControl _performKeyEquivalent:conditionally:] + 126 7 AppKit 0x00000001090b7e21 -[NSView performKeyEquivalent:] + 197 8 AppKit 0x00000001092e5613 -[_NSAlertContentView performKeyEquivalent:] + 88 9 AppKit 0x00000001090b7d47 -[NSView _performKeyEquivalent:conditionally:] + 189 10 AppKit 0x00000001090b7e21 -[NSView performKeyEquivalent:] + 197 11 AppKit 0x00000001090b7d47 -[NSView _performKeyEquivalent:conditionally:] + 189 12 AppKit 0x00000001090b7c15 -[NSWindow performKeyEquivalent:] + 78 13 AppKit 0x00000001091180ba -[NSWindow keyDown:] + 30 14 AppKit 0x000000010963411b -[NSWindow _reallySendEvent:isDelayedEvent:] + 5452 15 AppKit 0x0000000108fc5d76 -[NSWindow sendEvent:] + 470 16 AppKit 0x0000000108fc29b1 -[NSApplication sendEvent:] + 4199 17 iTerm2 0x00000001083259e9 -[iTermApplication sendEvent:] + 1577 18 AppKit 0x00000001090c19ef -[NSApplication _realDoModalLoop:peek:] + 770 19 AppKit 0x00000001090bdf76 -[NSApplication runModalForWindow:] + 119 20 AppKit 0x000000010916fa63 -[NSAlert runModal] + 144 21 iTerm2 0x00000001083c67c8 +[iTermWarning showWarningWithTitle:actions:accessory:identifier:silenceable:heading:] + 1016 22 iTerm2 0x00000001083c638b +[iTermWarning showWarningWithTitle:actions:identifier:silenceable:] + 43 23 iTerm2 0x0000000108283472 __23-[PTYTextView _allText]_block_invoke_2 + 114 24 libdispatch.dylib 0x000000010b69e323 _dispatch_call_block_and_release + 12 25 libdispatch.dylib 0x000000010b699c13 _dispatch_client_callout + 8 26 libdispatch.dylib 0x000000010b6a5cbf _dispatch_main_queue_callback_4CF + 861 27 CoreFoundation 0x000000010ab953f9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 28 CoreFoundation 0x000000010ab5068f __CFRunLoopRun + 2159 29 CoreFoundation 0x000000010ab4fbd8 CFRunLoopRunSpecific + 296 30 HIToolbox 0x00000001104e256f RunCurrentEventLoopInMode + 235 31 HIToolbox 0x00000001104e22ea ReceiveNextEventCommon + 431 32 HIToolbox 0x00000001104e212b _BlockUntilNextEventMatchingListInModeWithFilter + 71 33 AppKit 0x0000000108ef69bb _DPSNextEvent + 978 34 AppKit 0x0000000108ef5f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 35 AppKit 0x0000000108eebbf3 -[NSApplication run] + 594 36 AppKit 0x0000000108e68354 NSApplicationMain + 1832 37 iTerm2 0x0000000108259f29 main + 121 38 iTerm2 0x0000000108259ea4 start + 52 39 ??? 0x0000000000000001 0x0 + 1Ok, I tried both Build 2.9.20150519-nightly and Build 2.9.20150530-nightly, both had this issue as well. I then downgraded to the next oldest iTerm I had in my downloads, Build 2.9.20150430-nightly. This did not crash!
More specific steps to reproduce:
- Open new iTerm 2 session. SSH to another system, for example a CentOS 6 server
- Fill the buffer with 50,000 lines (I ended up using head -50000 /var/log/somehugelog.log for this)
- Attempt to use an aText macro in the same session / term. On Build 2.9.20150430-nightly there is a noticeable delay to aText rendering the macro but it does render (I've even had iTerm pinwheel before when doing this with a large buffer, yet it would still complete after a few seconds of waiting). On the later builds, this produces a crash, with the above crash log (though there's still noticeable delay between triggering the macro and the crash).
The version of aText is the same in all cases, the only variable is the build of iTerm I used.
It looks like an alertbox was shown before the crash (probably the "you're about to paste a bunch of lines" warning). Is that what you see?
Can you try this build of iterm2: http://iterm2.com/adhocbuilds/iTerm2-2_9_20150602_110052-adhoc.zip
and tell me what is appended to /var/log/syslog when you do the aText macro?
Hello George, Thank you for helping me with this! I do not see an alert box when this happens, though it is possible that is what iTerm is trying to do and just crashing before it actually renders. The text that triggers the macro is 5 characters long and the replacement text is 163 characters long in a single line -- one of several Bash one-liners I use for work, so the usual combination of backticks, pipes, greps and the like.
I was able to reproduce this on my local system (so no need to ssh it seems) by doing head -50000 somebiglog and then the macro.
I've attached the portion of system.log from when this occurred with the adhoc build as well as the crash log from the same
Thanks, Jeff
-
Looks like what's happening is we're showing a modal alert warning the user that accessibility may be hurting performance and the macro sends a kind of crazy NSEvent which triggers an exception in the framework. There are bugs all around! aText should not send broken events. The framework should be more forgiving of events. And iTerm2 shouldn't show modal alerts because they suck.
Reassigned to @gnachman
I wonder if TextExpander would trigger the same issue -- I use aText because it's cheaper and seems lighter weight to me. I'll check with my colleagues, see if anyone has TextExpander and if I can reproduce the same issue with it. But I'm with you on the modal alert, thanks for your time and for adding that to the list of future fixes. Sent you a donation, as other than this issue, iTerm2 has been awesome, and makes my job so much easier.
-
Modal alert changed to announcement in commit 14b1d1b9
