Htop on macOS High Sierra

[MenkeTechnologies]

Can anyone confirm the htop available on homebrew (2.02) is broken on macOS 10.13 (crashes iTerm2 after several seconds)?

[fykuan]

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]

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]

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]

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]

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.

[ghost]

After that, iTerm2 won't open again and macOS refuses to reboot.

What the ...

I am glad to say that htop for me, once compiled, always worked on Linux - I never had a situation where Linux would fail to reboot in such a situation ... :)

I guess for the time being one should not use htop on High Sierra until it is fixed; wonder what changed if it worked before ...

[spprichard]

I'm experiencing the same issue htop: 2.0.2 MacOS: 10.13(17A365). Anyone know a fix?

[roopej]

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]

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]

Does anyone else think its pretty weird that a crashing / mis-behaving htop process is able to ham up the kernel so much that it requires a system reboot?

[Nax]

It is indeed, this looks like htop may be starving some system resources, mach ports maybe?

[diclophis]

I was also running down a hunch that it had something to do with colored text rendering in both Terminal.app and iTerm2.app.... we noticed in our org some interesting properties around this crash..

1. if your running htop in Terminal.app, and it crashes, it can also crash a seperate iTerm2.app session
2. If you have htop running 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]

Another interesting aspect of this bug is that, after htop crashes, and locks the terminal app... the Activity Monitor.app fails to load and render processes as well!

[jiamo]

This may happened when some processes take much cpu and memory.

[nayzak]

This may happened when some processes take much cpu and memory.

XCode and SourceKitService always does :D

[lsk-boy-f]

hardware: Macbook pro 13' 2017
environment: htop 2.0.2, iTerm2 3.0.15, macOS: 10.13

I meet the same problem several times after I upgrade my system to macOS 10.13

[tnymlr]

I don't see how it's htop's problem. I believe that's some kind of a bug in mac OS kernel.

[damienstanton]

This was serious enough to cause kernel errors that prevented both iTerm and Terminal from opening, and no processes to be shown in Activity Monitor, as well as an indefinite hang on shutdown.

Looking at the console indicated a large number of deny fsctl errors but I don’t know if this is correlated.

Hard resetting the laptop, booting into safe mode and uninstalling htop via brew has resolved the issue in my case.

I’ll try to update this comment with more details when I have some time.

[BrandonNC]

I get the same thing, although my Mac can usually run for a few hours before the problem occurs; this may be due to the fact that I always run with -d50 for a 5 seconds refresh interval, which is slower than the default, so it might make sense that I can last a little longer.

[besmith43]

sudo htop seems to get around the problem for now.

on my machine it's normally seconds before htop freezes since upgrading to high sierra, but with sudo rights, it's been going strong for several hours.

[moritzreiter]

@besmith43 Hm, that would be quite a good workaround. But others reported here that it took several hours before the crash happened, so I'm not yet convinced that it's really safe.

By the way, I'm using glances at the moment. I don't like it as much as htop, but it's all right for the meantime.

[csi-adziahel]

confirming in htop 2.0.2, iTerm 3.1.4 and Terminal, MacOS 10.13

[vaquer]

Yes, htop seems to be broken on macOS 10.13. It's super weird that i can't restart the system normally and only restarted works by brute force after this bug occurs 😥

[joaomoreno]

Same.

[matthewbauer]

Has anyone reported this to Apple? I've got the same symptoms described here.

[Unayung]

same situation here. I was wondering if it's another APFS issue. seems I'm wrong then :D

[evanslify]

I'd like to look into what happened (for science?) but Certificate Manager is so broken that I can't get a certificate to codesign gdb right now....

[dylib]

I don't use Homebrew, although I installed htop via MacPorts — it appears to work without issue on macOS 10.13 (running over 12 hours):

$ sudo port install htop

$ htop

* it's unnecessary to run htop as sudo

[ilovezfs]

@monouser7dig OK. For you,

brew uninstall htop
git -C "$(brew --repo homebrew/core)" reset --hard
brew update
brew install htop

which should download and install the new bottle without the patch from #728.

[ylluminarious]

@JacobSyndeo Yes, according to others above, Apple has seemingly fixed this in 10.13.4. We are now worrying about users of previous versions of High Sierra since 10.13.4 hasn't even been released yet.

[ghost]

thanks ilovezfs!
(figured it out using cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula[master] and reset hard 😆 always an adventure using the homebrew folder/ link structure)

Apple has seemingly fixed this in 10.13.4

I think it's all good if that is the case 😄 let's see how htop 3 breaks It again, or not 😃

[ylluminarious]

@ilovezfs Hmm... so I tried to test things out earlier as you requested but I couldn't get the bug to happen at all in a VM. Even without your patch, I simply could not get the bug to happen. Even with the while true; do sh -c "exit 0"; done command, I could not get the system to hang or crash as it did on my real hardware. I am afraid to test out your patch outside of a VM, even on other hardware of mine since APFS is still relatively new, and although crash-protection is supposed to be in place now, I have been bitten by crashes before so I prefer to keep that feature in reserve for when an actual power outage occurs. I am afraid that someone else will have to test it unless there is a very confident assurance that someone can give that the new patch will actually work.

[ilovezfs]

@ylluminarious see #728 (comment)

[ylluminarious]

@ilovezfs Thanks, I'll chime in there.

[ghost]

fwiw macOS 11.13.4 (just released) with homebrew htop 2.1.0 works for me for over 1h now and even with while true; do sh -c "exit 0"; done

btw. I had no data loss whatsoever with APFS yet even though the crashes with htop or anything but if you want to be better safe than sorry..

[JudeQuintana]

same, latest htop has been running smooth for over 12 hours on 10.13.4, no issues

[ilovezfs]

FYI the problematic feature is entirely disabled in 2.1.0, so those results are not surprising. I don't doubt that it's fixed in 10.13.4, but still.

[Smattr]

Something I haven't seen discussed here, on #728, or #772 is that the problematic function at the root of this, task_for_pid, is marked obsolete in the Mach headers (mach/mach_traps.h). While the underlying cause may have been a kernel bug, it seems clear Apple themselves are not using this function. Perhaps they even intend to remove it in future. Should htop move to using a different interface for this functionality?

For reference, top on macOS does the reverse; tracks PIDs and uses pid_for_task. Having said that, pid_for_task also falls in the obsolete section in the Mach headers.

[ylluminarious]

@Smattr If that function is obsolete, what is the recommended alternative?

[saagarjha]

Apple themselves are not using this function

No, they very much are. See for example LLDB. There really is no replacement for task_for_pid that I'm aware of.

[pmalhaire]

It's common for apple to deprecate api with no alternative. The team in charge of the kernel seems to be too small.

[saagarjha]

task_for_pid is a critical component of XNU, though. It’s used heavily throughout the system.

[evanslify]

I thought the problem to blame is within taskgated?

[ylluminarious]

@evanslify It seems to be a mixed problem... both DarwinProcess_scanThreads and unelevated privileges are what cause the problem, but it must happen with both together, not separated.

[ylluminarious]

@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]

@ilovezfs @hishamhm Just in case my above comment isn't clear: I left htop running for 4 hours on 10.13.3 with @pmalhaire's patch in #772 and I didn't crash. His patch should be merged.

[mschwartz]

Installs with homebrew on high sierra and works!

[dylib]

@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.

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.4
BuildVersion:	17E199
$ ./htop -v
htop 2.1.0 - (C) 2004-2018 Hisham Muhammad
Released under the GNU GPL.

If I encounter anything I'll be sure to report back; I'm curious also about the MacPorts version too, so I'll install that later today and report back the result — cheers!

[ylluminarious]

@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]

+1, If we cannot reproduce this anymore and there's no new reports related to this issue, than we can close this.

[ylluminarious]

@neverpanic FYI, while this is still open, you might want to update the htop Macport once again to 2.2.0.

[ylluminarious]

@neverpanic Thanks! Just noticed the update.

[Paulomart]

For everyone experiencing this on remote ssh hosts:

Removing this line from /etc/ssh/sshd_config:

AcceptEnv LANG LC_*

fixed it for me.

[Zenexer]

@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.