When we close the application using the quit function F10, the last line
is cleared so that on terminals which do not support ALTBUF the last
line is not clobbered. This do not happen when the application exits as
a result of a signal (SIGINT,SIGTERM,SIGQUIT).
Move the logic to clear the last line into the CRT_done function. This
ensures that it will be executed when the CRT_handleSIGTERM is called.
The signal handler will access the Settings struct, which gets freed at
normal program finalization.
When using leak sanitizers with ASAN_OPTIONS=abort_on_error=1, which
runs after program termination, any leak causes SIGABRT to be raised,
calling the crash handler, which will derefernce the freed Settings.
==44741==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000000080 at pc 0x0000005680df bp 0x7fffe335e960 sp 0x7fffe335e958
READ of size 8 at 0x60d000000080 thread T0
#0 0x5680de in Settings_write /home/christian/Coding/workspaces/htop/Settings.c:329:26
#1 0x4f77b7 in CRT_handleSIGSEGV /home/christian/Coding/workspaces/htop/CRT.c:1020:4
#2 0x7f8a1120c13f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f)
#3 0x7f8a11042ce0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
#4 0x7f8a11042ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3
#5 0x7f8a1102c536 in abort stdlib/abort.c:79:7
#6 0x4c3db6 in __sanitizer::Abort() (/home/christian/Coding/workspaces/htop/htop+0x4c3db6)
#7 0x4c2090 in __sanitizer::Die() (/home/christian/Coding/workspaces/htop/htop+0x4c2090)
#8 0x4d0a17 in __lsan::HandleLeaks() (/home/christian/Coding/workspaces/htop/htop+0x4d0a17)
#9 0x4cd950 in __lsan::DoLeakCheck() (/home/christian/Coding/workspaces/htop/htop+0x4cd950)
#10 0x7f8a110454d6 in __run_exit_handlers stdlib/exit.c:108:8
#11 0x7f8a11045679 in exit stdlib/exit.c:139:3
#12 0x7f8a1102dd10 in __libc_start_main csu/../csu/libc-start.c:342:3
#13 0x428a19 in _start (/home/christian/Coding/workspaces/htop/htop+0x428a19)
0x60d000000080 is located 64 bytes inside of 144-byte region [0x60d000000040,0x60d0000000d0)
freed by thread T0 here:
#0 0x4a4f72 in free (/home/christian/Coding/workspaces/htop/htop+0x4a4f72)
#1 0x566693 in Settings_delete /home/christian/Coding/workspaces/htop/Settings.c:32:4
#2 0x4ede10 in CommandLine_run /home/christian/Coding/workspaces/htop/CommandLine.c:393:4
#3 0x4d6f32 in main /home/christian/Coding/workspaces/htop/htop.c:15:11
#4 0x7f8a1102dd09 in __libc_start_main csu/../csu/libc-start.c:308:16
previously allocated by thread T0 here:
#0 0x4a5372 in __interceptor_calloc (/home/christian/Coding/workspaces/htop/htop+0x4a5372)
#1 0x57f61a in xCalloc /home/christian/Coding/workspaces/htop/XUtils.c:55:17
#2 0x5688a6 in Settings_new /home/christian/Coding/workspaces/htop/Settings.c:392:21
#3 0x4ecb57 in CommandLine_run /home/christian/Coding/workspaces/htop/CommandLine.c:303:25
#4 0x4d6f32 in main /home/christian/Coding/workspaces/htop/htop.c:15:11
#5 0x7f8a1102dd09 in __libc_start_main csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: heap-use-after-free /home/christian/Coding/workspaces/htop/Settings.c:329:26 in Settings_write
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
Currently htop does not support offline CPUs and hot-swapping, e.g. via
echo 0 > /sys/devices/system/cpu/cpu2/online
Split the current single cpuCount variable into activeCPUs and
existingCPUs.
Supersedes: #650
Related: #580
This commit is based on exploratory work by Sohaib Mohamed.
The end goal is two-fold - to support addition of Meters we
build via configuration files for both the PCP platform and
for scripts ( https://github.com/htop-dev/htop/issues/526 )
Here, we focus on generic code and the PCP support. A new
class DynamicMeter is introduced - it uses the special case
'param' field handling that previously was used only by the
CPUMeter, such that every runtime-configured Meter is given
a unique identifier. Unlike with the CPUMeter this is used
internally only. When reading/writing to htoprc instead of
CPU(N) - where N is an integer param (CPU number) - we use
the string name for each meter. For example, if we have a
configuration for a DynamicMeter for some Redis metrics, we
might read and write "Dynamic(redis)". This identifier is
subsequently matched (back) up to the configuration file so
we're able to re-create arbitrary user configurations.
The PCP platform configuration file format is fairly simple.
We expand configs from several directories, including the
users homedir alongside htoprc (below htop/meters/) and also
/etc/pcp/htop/meters. The format will be described via a
new pcp-htop(5) man page, but its basically ini-style and
each Meter has one or more metric expressions associated, as
well as specifications for labels, color and so on via a dot
separated notation for individual metrics within the Meter.
A few initial sample configuration files are provided below
./pcp/meters that give the general idea. The PCP "derived"
metric specification - see pmRegisterDerived(3) - is used
as the syntax for specifying metrics in PCP DynamicMeters.
One review request relating to the PCP platform is to have
a clearly separate binary from the regular htop so that we
have no confusion as to what is being requested to run, to
aid debugging, and a bunch of other good reasons.
This commit renames htop.c to CommandLine.c and provides a
minimal htop main function for 'native' platforms to use.
The PCP version of this will setup libpcp.so and then call
the same CommandLine_run function as regular htop.
Related to https://github.com/htop-dev/htop/pull/536
Follow up on the two items of feedback from cgzones review,
and resolve a build failure picked up by CI on Mac OS X.
Related to https://github.com/htop-dev/htop/pull/564
The libcap code is Linux-specific so move it all below
the linux/ platform subdirectory. As this feature has
custom command-line long options I provide a mechanism
whereby each platform can add custom long options that
augment the main htop options. We'll make use this of
this with the pcp/ platform in due course to implement
the --host and --archive options there.
Related to https://github.com/htop-dev/htop/pull/536
Writing to the file stream might fail due to a immutable file or a
filesystem error.
Check the error indicator for the stream and for fclose() failures.
The State struct holds a pointer to the main process panel.
Use the distinct MainPanel type, to improve maintainability regrading
its usage.
This avoids usages of down-casts from Panel to MainPanel, only up-casts
from MainPanel to Panel are now required.
Use only one enum instead of a global and a platform specific one.
Drop Platform_numberOfFields global variable.
Set known size of Process_fields array
Implements the suggestion from https://github.com/htop-dev/htop/issues/399#issuecomment-747861013
Thanks to the refactors from 0bd5c8fb5da and 6393baa74e5, this was really easy
and clean to do.
It maintains the "Tree view always by PID" option in the Settings, which
results in some specific behaviors such as "clicking on the column header to
exit tree view" and "picking a new sort order to exit tree view", for the sake
of the muscle memory of long time htop users. :)
All calls to ScreenManager_new always pass the same first
five values, the orientation is always HORIZONTAL and the
y1 parameter is always the height of the passed-in header
struct pointer. I think its safe to assert at this point
that no VERTICAL orientation will arrive (if it does, its
no harm in re-adding this then) - so we can remove unused
conditionals (and TODOs) based on orientation too.
Move platform-specific code out of the htop.c main function
and into the platform sub-directories - primarily this is
the Linux procfs path check and sensors setup/teardown; not
needed on any other platforms. No functional changes here.
Hisham Muhammad
Emmanuel Mathi-Amorim
Volodymyr Vasiutyk
наб
Daniel Lange
Nathan Scott
Christian Göttsche
Sohaib Mohamed
nia
Benny Baumann