iTerm 2-tmux: infinite loop after re-attachment due to malformed history line
By sam.homer... on January 31, 2013 07:47 (imported from Google Code)
What steps will reproduce the problem?
- Open SSH connection to Linux server that has iTerm2-enabled tmux
- Run 'tmux -C' on remote host
- Use 'cat' to add lines to tmux session history
- In iTerm2, go to the tmux console window and hit escape to detach
- Run 'tmux -C attach' on remote host to re-attach
What is the expected output? What do you see instead?
Expected result: iTerm2 re-attaches to the remote tmux session.
Actual result: iTerm2 gets into an endless loop and allocates memory until it is killed (several GB).
What version of the product are you using? On what operating system?
Local:
MacBook 5,1 with 8GB RAM, running OS X 10.8.2
iTerm2: Several versions, including the canary binary from 2013-01-22, custom builds from https://github.com/gnachman/iTerm2 master
Remote:
A 32bit Debian Squeeze vServer with GCC 4.4.5
A 32-core, 256GB RAM Dell compute server running Redhat Enterprise Linux 6 with custom-compiled GCC 4.4.7
tmux2: Several versions, including the one built with the source included in the canary from 2013-01-22, custom builds from https://github.com/gnachman/tmux2/tree/mountainlion, all compiled against libevent2-2.0.21-stable.
Please provide any additional information below.
A debug log excerpt of iTerm2 (from Github master) is attached. Search for "MALFORMED LINE BELOW". At the bottom of the file is the point where it enters an endless loop, because the loop variable 'i' is no longer being incremented in file "TmuxHistoryParser.m", function "dataForHistoryLine", line 130.
I have added some debug output in Xcode, which demonstrates the issue and terminates the loop early by returning nil. This causes an exception and thus delays the memory bomb significantly. The patch with this early loop termination and additional debug logging is attached.
I tried both zsh and bash on the remote host without any config files, as well as tmux without tmux.conf. I also erased my iTerm2.plist and it made no difference at all.
The issue does not occur 100% predictably, but it might be related to what characters are part of the history. To verify that, I used 'cat' to display my ZSH config files, which sooner or later (after about 1500 lines) triggered the issue. In contrast, a file that has 10,000 lines of 80 zeros ('0') did not trigger the issue, even after I displayed it a dozen times.
If I attach to the remote tmux without the '-C' flag, I can close the window that contains the "bad history" and subsequently attach with '-C' again.