OOM + Closing tabs after session restore is O(n²)?
Bug report
Thanks for filing an issue! Please answer the questions below so I can help you.
- iTerm2 version: Build 3.4.19
- OS version: 13.1 (22C65)
- Attach
~/Library/Preferences/com.googlecode.iterm2.plist
here (drag-drop from finder into this window) com.googlecode.iterm2.plist - Attach a debug log, if possible.
- Attach a screen capture video if it would make the reproduction steps clearer.
PLEASE ATTACH YOUR PLIST FILE FOR BUG REPORTS! Seriously! I'll probably ask you for it if you don’t.
Detailed steps to reproduce the problem
For the OOM, I am unsure.
For the session-restore-tabs-close, I think/hope it is as simple as stress testing session restore:
- Have a session crash. Have a lot of tabs open. I don't think they need to be anything particularly fancy; most of mine after a restore are just
zsh
. (As typically, iTerm2 appears to lose the content. This is fine with me.) - Attempt to close a tab: for me, the first tabs to close take ~40 seconds.
What happened
-
iTerm2 sometimes crashes like this:
(The value macOS gives here is perplexing. My MBP has 32 GiB of RAM, and ~24 GiB of free disk; not nearly enough to support that. I don't know if macOS can compress RAM, or something? I do suppose that if this is a leak of the same data, repeatedly, and macOS can compress RAM, then perhaps it makes sense, as the leaked data would be highly compressible. But it's interesting, nonetheless.)
-
After killing it (via that same dialog), restarting iTerm2 causes it to attempt to restore the session. It seems, in this case, it is unable to restore the contents of tabs, though it is able to restore the command that is running?
It doesn't much matter to me: when the above happens, I usually just discard the state of the terminals anyways; they're too unrecognizable to me, and might as well use the opportunity to start fresh.
-
I close a tab. In the restored session I just killed off, this takes 40 seconds. For a single tab.
-
1h 20m of wall clock time later, the last tab is closed. During this time, while a tab is closing, iTerm2 is consuming 100% CPU:
-
Over the 1h 20m it took me to close the tabs, iTerm2 consumed 1h 7m of CPU time:
I've done nothing with iTerm2 by that point, except close tabs. (Suffice it to say I read a lot of Hacker News in that time.)
Some notes:
-
When I close a tab, the "tab switch" to the next tab in the tab bar happens pretty quick. The tab bar appears to be mid animation: there's a large grey square next to the now selected tab. I think this is, essentially, the first frame in the animation of the remaining tabs sliding over into its place. On the newly selected tab is a yellow butter bar; IIRC it is apologizing I think for not being able to correctly restore the session. Mousing over this bar gets a beachball for some (variable-ish, see below) time. Eventually, the tab becomes response, I close it, rinse, repeat.
-
As I close tabs, the length of time a tab is unresponsive is high at first, and quite quick once we have less tabs, and it trends from 40s at the start to well under a second by the last tab. If I had to put money on it, it feels like accidentally quadratic behavior, and as tabs are closed, it gets better.
-
The butter bar appears to have an input race condition: the butter bar announces that it can be dismissed with any key. Pressing "ESC ^D", for example, prior to the bar being able to dismiss, causes the ^D to be lost. (I.e., any additional keystrokes after the initial one but prior to the bar disappearing are eaten, AFAICT, by the bar.)
Under normal circumstances, this would probably be pretty hard to trigger, as the bar would dismiss itself before a human could enter the next keystroke. At 40s latency, of course, it's a different store.
I mention this only as it hampers my ability to just queue up a bunch of ESC ^D ESC ^D … to dismiss a long sequence of tabs while I got read some HN.
-
My scrollback preference is set to 5,000 lines / unlimited scrollback is disabled. (I.e., the RAM usage at the start shouldn't be from a runaway scrollback buffer.)
What should have happened
Tabs should close a bit faster, and ideally, iTerm2 shouldn't consume 200 GiB of RAM!