Htop: no threads shown in OSX

[robaho]

I use the 'H' to show threads, but on my OSX El Capitan machine, it doesn't appear to do anything. I am trying to use htop to view the threads on a Java process.

The reason I can tell it is not working, is because the PID is the same, and yet it shows > 100% cpu, so it cannot possibly be a thread - it is still the process.

Is there some other setup that needs to be done?

[hishamhm]

Hi! What version of htop are you using?

[robaho]

2.0.2

On September 4, 2016 2:46:23 AM CDT, Hisham Muhammad [email protected] wrote:

What version of htop are you using?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/hishamhm/htop/issues/552#issuecomment-244588975

[jelmerk]

I'd just like to chime in on this. Same issue for me

The brew version has this problem and I compiled the current master branch. Made sure hide userland threads is disabled in display options and no sigar

[relgames]

@jelmerk so does the master branch show threads?
I have the same issue, htop htop 2.0.2 does not show threads.

[relgames]

Checked on master b1028e03c513bc9182b7cc926170ce17a2bd0ac6 - no threads.

[hishamhm]

Last time I tried to improve the support for threads in htop on the Mac, I stumbled upon the fact that Apple does not allow non-signed binaries to access some thread-related APIs.

Since I don't have a Mac and I don't pay Apple for developer access to their platform, I have no way to provide these binaries or implement full thread info support. I did a crowdfunding effort a few years ago to sponsor hardware and development time for the Mac port, but it didn't reach its funding goal (it did pay for enough developer time to make the platform-abstraction layer that enabled the current Mac port, though). Also, in any case, providing updated binaries would require a regular expense of a yearly developer subscription, as far as I know.

I'd love to have Mac developers on board with the project willing to address these problems!

[danielsadoc]

is this still an issue in version 2.2.0? If so, is there any way to check, in MacOS, using htop, the user level threads shown by jstack? Is there any alternative to htop?

[robaho]

Still doesn’t work. The thread count shows - but you can’t see the threads nor their names - of any process, not just java

On Jun 25, 2018, at 3:52 PM, danielsadoc [e-mail] wrote:

is this still an issue in version 2.2.0? If so, is there any way to check, in MacOS, using htop, the user level threads shown by jstack?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/hishamhm/htop/issues/552#issuecomment-400091595, or mute the thread https://github.com/notifications/unsubscribe-auth/AEuqcScB_YWE16vBsCNAh5VAeHx2zmFLks5uAU2igaJpZM4Jy9d2.

[rickysland]

still doesn't work. so sad.

[gobwas]

The same problem for me on macOS Mojave.

[robaho]

@hishamhm hi, I've been working on getting the OSX thread support to work. If you run htop as root then you don't need the signed binary, or the embedded Info.Plist - although creating a self-signed certificate is trivial - I will probably create signed binaries from my forked repo.

Still, here is the problem. I've stepped through the code, and in DarwinProcess.c there is DarwinProcess_scanThreads(DarwinProcess *dp). It works, but it doesn't seem to return the thread info in anyway ???

What should this method being doing - pseudo code ?

[hishamhm]

It works, but it doesn't seem to return the thread info in anyway ???

Currently, this function scans threads looking for process state info only, and not to insert new entries in the process list.

[robaho]

I got it working on OSX. There are two major problems. The OSX "thread id" is not a PID - so you can have collisions. Even though there appears to be support in htop for a more advanced "pid compare" it isn't used with the hashtable. I still have to re-factor the cpu timing code, as it expects to get these timings from another system call instead of the "extended thread info". I pick up the thread name from there.

The solution I came up with is to make the TID negative and use it as the PID. Seems to work ok, but looks a little funky. I can probably change it during output to show the real TID in the TGID, and a '?' in the PID, when the "process" is a thread.

[robaho]

Here is under OSX where the threads are shown in green.

[robaho]

I also decided to not shown threads that didn't have a name.

[gobwas]

@robaho thanks, looks promising! By the way, why don't show unnamed threads? Sounds like unfair behavior?

[robaho]

There are usually a lot of unamed threads in a given app. Without a name there’s not a lot of diagnosis that can be done in htop. So I figured I’d get rid of the noise.

Sent from my iPhone

On Oct 31, 2018, at 1:22 AM, Sergey Kamardin [e-mail] wrote:

@robaho thanks, looks promising! By the way, why don't show unnamed threads? Sounds like unfair behavior?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[hishamhm]

@robaho Great news!

The pid/tid compare issue also came up in other OSes. There are workarounds (see the Solaris code, for example), but it looks like I need to stop treating the Linux assumption that each thread gets a unique PID as the default.

Regarding unnamed threads, in the Linux codebase, when a thread doesn't have a specific name it inherits the process name. It usually produces decent behavior. Looks like you're not collecting thread data for the other fields yet, but if you can get per-thread info like CPU usage, it's useful to have the unnamed threads show up because sometimes its one of the anonymous threads that's eating up the CPU.

[robaho]

@hishamhm I changed the code to use the parent process name when the thread name is empty. Yes, I think you need to treat the PID, and TID separately - The TID on OSX is 64 bits - so even the current hack is not fool-proof. If you made the lookup be PID+TID then even if the TID is truncated to 32 bits, it would probably be a rare collisions if at all.

[robaho]

@hishamhm I don't think the solaris method will work, since the TID on OSX are very large. I think the best solution is to make the change to treat a proc entry as PID & TID. On some OS, TID = PID. The compare is already done, it is just the hashtable that needs to use both fields.

[robaho]

@hishamhm I created the PR for this. https://github.com/hishamhm/htop/pull/848