Coverity scan reports there may be a code path that would cause
an overrun in the (relatively new) ScreenSettings code where it
evaluates default sort direction. Add bounds check and default
to descending instead of a potentially invalid array access.
If the max PID or UID value for a platform is exactly a power of ten
(10000, 100000, etc.) the column widths of PID and UID would be 1 char
less than the correct number of digits. This is caused by the wrong
rounding function (ceil(x)); change to the correct one (trunc(x) + 1).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Get this warning when compiling Settings.c on the Mac OS X with clang-800.0.42.1.
Settings.c:447:28: warning: comparison of unsigned enum expression < 0 is always false [-Wtautological-compare]
if (this->hLayout < 0 || this->hLayout >= LAST_HEADER_LAYOUT)
~~~~~~~~~~~~~ ^ ~
This patch fixes the problem.
Retrieve hwloc dependencies through pkg-config to avoid the following
static build failure:
checking for hwloc_get_proc_cpubind in -lhwloc... no
configure: error: can not find required library libhwloc
This build failure is raised because without pkg-config, hwloc
dependencies such as libxml2 are not retrieved:
configure:8999: checking for hwloc_get_proc_cpubind in -lhwloc
configure:9022: /home/autobuild/autobuild/instance-0/output-1/host/bin/powerpc-buildroot-linux-uclibc-gcc -o conftest -D_GNU_SOURCE -I/home/autobuild/autobuild/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/usr/bin/../../usr/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Og -g0 -static -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -static conftest.c -lhwloc -llzma -L/home/autobuild/autobuild/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/usr/bin/../../usr/lib -lncurses -lm >&5
/home/autobuild/autobuild/instance-0/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibc/10.3.0/../../../../powerpc-buildroot-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-0/output-1/host/powerpc-buildroot-linux-uclibc/sysroot/usr/bin/../../usr/lib/libhwloc.a(topology-xml-libxml.o): in function `hwloc_libxml_free_buffer':
topology-xml-libxml.c:(.text+0x6a): undefined reference to `xmlFree'
Fixes:
- http://autobuild.buildroot.org/results/5d815ec08c580005a863df6ac9ac29deff7d4128
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
At the moment this is used to make the memory meter report sane values even
if the host has ZFS and that leaks through into a containerized environment
Fixes#863
Includes a clever check for magic PROC_PID_INIT_INO in /proc/self/ns/pid thanks to Pavel Snajdr (snajpa)
This enables:
* Multiple filters in the main panel and strace etc. views
* Multiple search terms
The search terms are separated by "|" and are still fixed strings
matched case-insensitive.
Added a multi flag at request of BenBE.
SELinux contexts can be quite long; adjust the column width dynamically
at each cycle to the longest value.
Also with the recent addition of multiple screens, over-long columns can
be moved into their own screen.
Depending upon default behavior of the compiler and floating-point
environment, compiler could round down the value between "99.9" and
"100.0" to "99.0", instead of rounding it to the nearest value, "100.0".
Note: The floating-point environment access and modification is only
meaningful when "#pragma STD FENV_ACCESS" is set to "ON"[1]. Otherwise
implementation is free to assume that floating-point control modes are
always the default. So it would be a good idea to address the rounding
ambiguity between "99.9" and "100.0" to become compiler agnostic.
[1]: https://en.cppreference.com/w/c/numeric/fenv
Credits: @Explorer09, thanks for the suggestion.
When we run a process which utilizes CPU between 100.0% and 999.9%, htop
shows an unnecessary decimal character at the end of the value. For
example, '100.x' and '247.x' become '100.' and '247.' respectively.
When CPU utilization is less than and equal to '99.9%', show the result
with single digit precision and if result is less than four characters,
pad it with the blank space. When CPU utilization is greater than
'99.9%', show only integral part of the result and if it's less than
four characters, pad it with the blank space.
Closes: #946
Fetching the TTY name of a process is extremely expensive on darwin and
the call to devname accounts for 95% of htop's CPU usage when there is
high process turnover (this is mostly due to devname calling lstat,
which is incredibly slow). This can make htop unresponsive.
To mitigate this only set the process TTY name if the it is being
actively displayed (PROCESS_FLAG_TTY), which by default it is not
on darwin.
ProcessList_buildTree does not need any particular sort order for
children of the same process or roots. Switching these to the sort order
configured by the user produces sorted tree automatically, making repeat
sort unnecessary.
ProcessList_buildTreeBranch used to search for children with a linear
scan of the process table, which made tree build time quadratic in
process count. Pre-sorting the list by parent PID (if known) makes it
possible to select the correct slice by bisection much faster.
Separate `processes` (the vector owning the processes, sorted in
whatever order is needed right now internally) and `displayList` (a
vector referencing the processes in the same order they're to be
displayed).
Special-casing hidden processes does not serve any obvious purpose and
depends on the move from processes to processes2 which will be removed
in a later commit.
htop is a program which will be run on CHOST after cross-compilation;
CTARGET is only for a small number of cases where a program itself outputs
code (so you might cross-compile a compiler which spits out code for a third
architecture/platform).
We want to use AC_CANONICAL_HOST to check CHOST for the platform currently
being used to build htop.
The confusion around this issue was compounded by a mistake in autoconf-archive
which has since been fixed (AX_PTHREAD pulled it in incorrectly).
See: https://github.com/libstatgrab/libstatgrab/pull/131
See: https://github.com/fenrus75/powertop/pull/90#discussion_r705803725
Signed-off-by: Sam James <sam@gentoo.org>
Nathan Scott