While most Unix-like systems use 16-bit user IDs,
Linux supports 32-bit UIDs since version 2.6.
UIDs above 65535 are used for UID namespacing of containers,
where a container has its own set of 16-bit user IDs.
Processes in such containers will have (much) larger UIDs than 65535.
Because the current format strings for `ST_UID` and `USER`
are `%5d` and `%9d` respectively, processes with such UIDs
lead to misaligned columns.
Dynamically scale the `ST_UID` column and increase the size of `USER`
to 10 characters (length of UINT32_MAX) to ensure that the user ID always fits.
Additionally: clean up how the titlebuffer size calculation and ensure
the PID column has a minimum size of 5.
Limit the maximum width (instead of only the minimum width), pad the
header width accordingly, and also remove extra stray spaces from the
format string (the main spacing should just come from the alignment of
the value).
Fixes#850.
The names array is terminated by a NULL entry, thus allocate space for
one more than entries.
Fixes: #844
==6708==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000045b8 at pc 0x000000589ee1 bp 0x7ffcd1dee220 sp 0x7ffcd1dee218
READ of size 8 at 0x6060000045b8 thread T0
#0 0x589ee0 in String_freeArray ./XUtils.c:157:23
#1 0x56c9af in Settings_delete ./Settings.c:31:7
#2 0x4ee44b in CommandLine_run ./CommandLine.c:395:4
#3 0x4d6fb2 in main ./htop.c:15:11
#4 0x7ff3b8154e49 in __libc_start_main csu/../csu/libc-start.c:314:16
#5 0x428aa9 in _start (./htop+0x428aa9)
0x6060000045b8 is located 0 bytes to the right of 56-byte region [0x606000004580,0x6060000045b8)
allocated by thread T0 here:
#0 0x4a53f2 in __interceptor_calloc (./htop+0x4a53f2)
#1 0x5890ba in xCalloc ./XUtils.c:55:17
#2 0x50a044 in Header_writeBackToSettings ./Header.c:148:34
#3 0x4de861 in Action_runSetup ./Action.c:91:7
#4 0x4de861 in actionSetup ./Action.c:386:4
#5 0x515caf in MainPanel_eventHandler ./MainPanel.c:106:19
#6 0x56a5c1 in ScreenManager_run ./ScreenManager.c:235:19
#7 0x4ee13b in CommandLine_run ./CommandLine.c:364:4
#8 0x4d6fb2 in main ./htop.c:15:11
#9 0x7ff3b8154e49 in __libc_start_main csu/../csu/libc-start.c:314:16
This is real, physical memory available for applications to
use. We should not try to pretend otherwise; its confusing
for users and inconsistent with all other tools.
This situation can arise if pcp-htop screen is resized right
at the same time sampling from pmcd(1) is happening. Have a
couple more goes at it before giving up entirely; once there
is no data available though we cannot proceed into accessing
the sample result data structure (segv will result) so a new
short-circuit guard is added there also.
This closes a nasty memory leak. There is at least another leak looming somewhere when Disk I/O is shown in the header area. That could very well be an issue within libdevstat native to FreeBSD.
Add an explicit else clause so a following else branch for a prior if
condition does not get mixed up.
Also force a trailing semicolon and thereby silence current
-Wextra-semi-stmt warnings.
Improve readability of the hwloc_bitmap_foreach_begin loop macro.
Insert space padding between a header (e.g. 'if', 'for', 'while'...) and the
following paren. ex:
if(isFoo((a+2), b))
bar(a, b);
becomes:
if (isFoo((a+2), b))
bar(a, b);
Link: http://astyle.sourceforge.net/astyle.html#_pad-paren
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Fixes builds failing with error
MainPanel.c:65:62: error: 'Settings {aka struct Settings_}' has no member named 'enableMouse'
if (ch != ERR && (ch != KEY_MOUSE || this->state->settings->enableMouse))
A process, whose executable has been replaced and thus marked by htop,
can be re-executed with the replaced executable, with the same PID, in
two ways: the Linux feature checkpoint/restore or re-execution of PID 1.
The actual check is just a string comparison, like the dropped
condition, leading to (almost) no computation overhead.
