After being broken for far too long, htop works again (hooray). htop no longer crashes shortly after startup.
I am trying to improve htop's working state so that people start using it again and can depend on it. Towards this end I need people to run htop, test htop, crash htop, and send coredumps to me. For some reason, systems with hw.ncpu=8 (eight "core" systems) tend to crash htop more frequently; coredumps from such machines are especially helpful. I have htop building with debugging symbols left unstripped. If you send me a coredump, please make sure it is from a binary built from the latest REVISION (6 as of writing). Some technical details: htop on OpenBSD is a special case -- we don't run the normal portable code that every other OS runs as it relies on procfs data. We have our own special code seperate from htop proper that understandably isn't afforded the same level of attention. This is why htop runs so weirdly on OpenBSD. Instead of procfs, htop uses sysctl(3) to gather processor metrics. Interestingly enough (I did not realize this prior to working with htop) the command line sysctl(8) utility only exposes a small subset of what is actually possible through the sysctl(3) system call. In htop's case, we pull temporal per-processor statistics using KERN_CPTIME2, which gives us CPUSTATES (six) values, of which only CP_IDLE is relevant. htop was broken for a few months -- after the addition of a new CPUSTATE (https://marc.info/?l=openbsd-cvs&m=152630109526317&w=2) re-indexed the CPUSTATES in sched.h, htop's hard-coded values now sampled the wrong metric, resulting in perpetually zero activity on the meters. THe memory management for the OpenBSD-specific code is a bit wonky, we have commented out a lot of free()'s because they are run too early & crash htop -- tradeoff is memory leaks. Best, Ian Sutton
