This fixes an issus in Hashtable_dump where `"(nil"` is passed as an
argument to `%p` in fprintf. This prints the static address of `"(nil)"`
not "(nil)". This commit changes the code to just pass the NULL pointer
to fprintf, which will consistently print "0x0".
As the "highlight dying processes" option has to keep processes in the
list when they disappear, no code except the cleanup loop in
`ProcessList_scan` should remove processes from the list directly.
Remove the export to prevent random process removals from being
reintroduced accidentally.
If a process goes away while reading its fields, but we already have
that process in the list, we should keep it in case the "highlight dying
processes" mode is active. Not only is that expected in this mode, but
this should also ensure parents are in the list when their children are
(wanted for tree mode consistency).
A process can die between reading the directory listing and opening the
directory FD (if HAVE_OPENAT) or /proc files (otherwise) for reading the
process data. This race would cause LinuxProcessList_recurseProcTree to
remove it from the list immediately, which is unexpected in the
"highlight dying processes" mode and can break the tree structure.
This patch closes this race in the HAVE_OPENAT case by only accessing
the process entry after the directory FD has been opened.
man sscanf(3):
A sequence of white-space characters (space, tab, newline, etc.; see isspace(3)).
This directive matches any amount of white space, including none, in the input.
This commit changes ProcessList_scan to lazily remove Processes by
index, which is known, instead of performing a brute-force search by
pid and immediately reclaiming the lost vector space via compaction.
Searching by pid is potentially quadratic in ProcessList_scan because
the process we are searching for is always at the back of the vector
(the scan starts from the back of the vector). Additionally, removal
via Vector_remove immediately reclaims space (by sliding elements
down).
With these changes process removal in ProcessList_scan is now linear.
Changes:
* ProcessList: add new ProcessList_removeIndex function to remove
by index
* Vector: add Vector_softRemove and Vector_compact functions to
support lazy removal/deletion of entries Vector_softRemove
Vector_compact
* Vector: replace Vector_count with Vector_countEquals since it only
used for consistency assertions.
Coverity scan reports that there is dead code in Settings_write
checking for nulls that have already been dereferenced on every
code path leading to the check. This is likely a hangover from
times when the screens pointer was only conditionally allocated
- they're not needed anymore.
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.
Charlie Vieth
Denis Lisov
Daniel Lange
Christian Göttsche
Nathan Scott
Nathan Scott
Benny Baumann
Explorer09
ahsmha
hwangcc23
Fabrice Fontaine
er-azh
HeshamTB
Kumar