Meter.c:320:71: warning: performing an implicit widening conversion to type '__suseconds_t' (aka 'long') of a multiplication performed in type 'int' [bugprone-implicit- widening-of-multiplication-result]
struct timeval delay = { .tv_sec = globalDelay / 10, .tv_usec = (globalDelay - ((globalDelay / 10) * 10)) * 100000 };
^
Found by clang-tidy.
home/christian/Coding/workspaces/htop/Process.c:505:13: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
WRITE_HIGHLIGHT(0, strlen(procComm), commAttr, CMDLINE_HIGHLIGHT_FLAG_COMM);
^
/home/christian/Coding/workspaces/htop/Process.c:461:13: note: expanded from macro 'WRITE_HIGHLIGHT'
continue; \
^
The main change is the header hight being not included in y1.
This is important if a sub-manager gets resized, e.g. a resize while
editing the Settings or in a pickFromVector selection, and afterwards,
then the sub-manager is closed, the super-ScreenManager gets resized, it
uses the correct header hight.
The header hight might have been changed since the last resize of the
super-manager in the Settings by adding/removing some meters.
This fixes new meters being hidden after added at runtime after a resize
in the main window.
This cannot be negative in these code locations, but for the
purposes of static checking like Coverity scan make it clear
and used the same unsigned type as ProcessList.h for the CPU
count variable (matching PL activeCPUs and existingCPUs).
This cannot happen in these code locations, but for the purposes
of static checkers like Coverity scan (and for future proofing),
add two more guards on NULL hash table entry pointers.
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
Querying kernel threads with `ps -o pid,lid,flags,state,lname -sp 0`
gives that kernel threads have state `K` and flags have mask `0x20000` set.
This corresponds to `LW_SYSTEM` in kernel which is mapped as `L_SYSTEM`/`P_SYSTEM` for userspace.
Update merged command-line when started with "Show custom thread names"
disabled and enabling at runtime.
Also only consider showThreadNames when working on userland threads.
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.
Daniel Lange