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
This adds a configure check for the ncurses getmouse() function
and disables mouse-related code paths when mouse support is
not present in the curses library.
This is necessary for stable versions of NetBSD's libcurses, the
development version has stub mouse functions for compatibility
with ncurses.
Signed-off-by: Nia Alarie <nia@NetBSD.org>
This SIGINT handler is installed on top of an optional
handler that some curses/ncurses implementations provide.
This ensures the curser is properly reset when hitting Ctrl+C.
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.
Allow other projects (PCP) to be able to ship an htop binary
which uses the custom name (pcp-htop) in several diagnostics
so that its clear which (if any!) binary failed.
Always show the number of kernel and userland threads, even when they
are disabled to not be shown in the process list.
The data is already available and might improve understanding the system
utilization.
Use a shadow color in case the kind of thread is hidden, else the normal
meter one.
This prefers the `#if defined()` syntax over the `#ifdef` variant
whenever there's also a `#elif defined()` clause, thus making the
multiple branching structure more obvious and the overall use
more consistent.
This support was rarely ever used and has been disabled by default for some time.
As far as the developer team is aware there's no distribution that activated this
feature in their packages by default.
According to the Linux kernel documentation, "SwapCached" tracks "memory
that once was swapped out, is swapped back in but still also is
in the swapfile (if memory is needed it doesn't need to be swapped out
AGAIN because it is already in the swapfile. This saves I/O)."
CRT.c:821:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#ifdef HAVE_EXECINFO_H
^
CRT.c:823:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#endif
^
CRT.c:858:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#ifdef HTOP_DARWIN
^
CRT.c:862:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#endif
^
CRT.c:864:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#ifdef HTOP_DARWIN
^
CRT.c:868:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#endif
^
Partially revert 4b14ab9789
ColorPair(Black,Black) is not actually black on black, but due to
adjustments in CRT_setColors() black on default-background-color.
Thanks to V for reporting.
By storing the per-process m_resident and m_virt values in the form
htop wants to display them in (KB, not pages), we no longer need to
have definitions of pageSize and pageSizeKB in the common CRT code.
These variables were never really CRT (i.e. display) related in the
first place. It turns out the darwin platform code doesn't need to
use these at all (the process values are extracted from the kernel
in bytes not pages) and the other platforms can each use their own
local pagesize variables, in more appropriate locations.
Some platforms were actually already doing this, so this change is
removing duplication of logic and variables there.
Daniel Lange