This repository was archived by the owner on Sep 8, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 8, 2020. It is now read-only.
Htop on macOS High Sierra #682
Description
Can anyone confirm the htop available on homebrew (2.02) is broken on macOS 10.13 (crashes iTerm2 after several seconds)?
Reacted by Lluís Ulzurrun de Asanza Sàez, Tomáš Hartmann, Sergei Aleksandrovich, Tomek Romik, Andrey Viktorov, Leonardo Quixada, Ian Kazlauskas, Alexandre Côté, Maxime Bacoux, Lev and 193 more
Reacted by Jon Bardin, Maxime Bacoux, Andrey Dyagel, Frank, Gad Kadosh, eep, Urda, rolight, Roman Plášil, Christian Speckner and 49 more
Activity
fykuan commentedon Sep 26, 2017
I am facing a similar issue. After several seconds running htop in iTerm2 (and Terminal.app too). The terminal halts and I have to force close it. After that, iTerm2 won't open again and macOS refuses to reboot. I have to force reboot macOS by holding the power button.
moritzreiter commentedon Sep 28, 2017
I'm experiencing the exact same behavior as @fykuan describes with the only difference that htop can run for quite a while before it crashes on my machine, I'd estimate up to half an hour or so.
I just asked on apple.stackexchange.com about this and at least one person replied in the comments reporting the same problem.
I installed htop (version 2.0.2) with
brew install htop.This only started happening after the upgrade to macOS 10.13 (High Sierra).
Nax commentedon Sep 28, 2017
I experience the same problem. Like @anothernode, it happens after a few hours on my machines.
Htop version 2.0.2, installed from MacPorts.
amertkara commentedon Sep 28, 2017
Having the same issue. iTerm runs fine on its own until I start htop. Initially htop runs fine but if I keep it running for a while (more than a couple of minutes), I see the spinning pointer and eventually have to force quit iTerm. I cannot start both iTerm and Terminal apps without restarting the laptop.
cusster commentedon Sep 29, 2017
Good to know I'm not the only one having this issue. Using iTerm2 and htop is installed using homebrew. Hopefully this gets fixed soon.
spprichard commentedon Oct 10, 2017
I'm experiencing the same issue htop: 2.0.2 MacOS: 10.13(17A365). Anyone know a fix?
roopej commentedon Oct 11, 2017
I can also confirm the same on macOS 10.13 with htop 2.0.2 running in iTerm2 build 3.0.3. After some time I get the spinning pointer. Activity Monitor goes totally blank and MBP needs to be rebooted.
nayzak commentedon Oct 11, 2017
Same issue. htop 2.0.2, iTerm2 3.1.3, macOS: 10.13.
After some time of running htop (could be less than a minute or several hours) iTerm hangs. Other apps are working but I can't launch new ones. Also running apps can't do IO operations, i.e. Safari opens new tab but not loading web page, AppCode infinitely tries to index project, Tunnelbrick seems to be disconnected. I had an idea that something happens with persistent storage like ssd was suddenly disconnected.
diclophis commentedon Oct 12, 2017
Does anyone else think its pretty weird that a crashing / mis-behaving
htopprocess is able to ham up the kernel so much that it requires a system reboot?Nax commentedon Oct 12, 2017
It is indeed, this looks like
htopmay be starving some system resources, mach ports maybe?diclophis commentedon Oct 13, 2017
I was also running down a hunch that it had something to do with colored text rendering in both
Terminal.appandiTerm2.app.... we noticed in our org some interesting properties around this crash..htopinTerminal.app, and it crashes, it can also crash a seperateiTerm2.appsessionhtoprunning in a terminal app, and its "minimized" it will run fine... up until the moment you bring the app into the foreground and make it visible...diclophis commentedon Oct 13, 2017
Another interesting aspect of this bug is that, after
htopcrashes, and locks the terminal app... theActivity Monitor.appfails to load and render processes as well!jiamo commentedon Oct 18, 2017
This may happened when some processes take much cpu and memory.
226 remaining items
saagarjha commentedon Mar 31, 2018
task_for_pidis a critical component of XNU, though. It’s used heavily throughout the system.evanslify commentedon Apr 2, 2018
I thought the problem to blame is within
taskgated?ylluminarious commentedon Apr 2, 2018
@evanslify It seems to be a mixed problem... both
DarwinProcess_scanThreadsand unelevated privileges are what cause the problem, but it must happen with both together, not separated.ylluminarious commentedon Apr 2, 2018
@ilovezfs @hishamhm @pmalhaire Looks like #772 fixes the problem for good and resolves the issues which I reported while testing @pmalhaire's initial patch in #728.
ylluminarious commentedon Apr 4, 2018
@ilovezfs @hishamhm Just in case my above comment isn't clear: I left
htoprunning for 4 hours on 10.13.3 with @pmalhaire's patch in #772 and I didn't crash. His patch should be merged.mschwartz commentedon Apr 8, 2018
Installs with homebrew on high sierra and works!
dylib commentedon Apr 9, 2018
@hishamhm, I compiled 2.1.0 and haven't had any issues whatsoever since running for over 48 hours in addition to
while true; do sh -c "exit 0"; done.If I encounter anything I'll be sure to report back; I'm curious also about the
MacPortsversion too, so I'll install that later today and report back the result — cheers!ylluminarious commentedon Apr 14, 2018
@hishamhm If you want to, I think this issue could (should) be closed now. With the release of macOS 10.13.4 and htop 2.2.0, I think we're out of the woods with this nasty bug.
evanslify commentedon May 10, 2018
+1, If we cannot reproduce this anymore and there's no new reports related to this issue, than we can close this.
ylluminarious commentedon May 10, 2018
@neverpanic FYI, while this is still open, you might want to update the
htopMacport once again to 2.2.0.htop: Update to 2.2.0
ylluminarious commentedon May 12, 2018
@neverpanic Thanks! Just noticed the update.
Paulomart commentedon Sep 15, 2019
For everyone experiencing this on remote ssh hosts:
Removing this line from
/etc/ssh/sshd_config:fixed it for me.
Zenexer commentedon Sep 15, 2019
@Paulomart, that's sort of a hackish solution. Instead of preventing those variables from being set, you should either install the correct locale on the remote host or choose a locale that your remote host already has.
Additionally, this issue is for htop running locally, not on a remote host; any problems you're experiencing as a result of an incorrect locale are most likely not related to the issue described here.