When displaying detailed cpu statistics, as opposed to
those scalable graphs, only two per line can be shown.
Therefore, if we are showing a detail version, our '4'
toggle must prematurely revert to single mode display.
Conversely, the 't' toggle must also turn off that '4'
toggle rather than try to print more than 2 abreast if
we're currently executing in detailed statistics mode.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When more than two cpus are displayed per summary area
line in graph form, those memory graphs were scaled to
that same width for consistency & aesthetics. However,
they probably shouldn't have been reduced to less than
terminal width due to a resulting loss of information.
[ after all, detailed memory stats are never reduced ]
So now, supporting logic was refactored to behave just
as it did before the 4 toggle was expanded beyond '1'.
[ the changes impact the 2 memory graphs exclusively ]
Reference(s):
https://www.freelists.org/post/procps/top-enhancements-2-bugs-swatted,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just supplements the previous series with a
few minor tweaks representing some diverse objectives:
. a recent date for man page (which i always overlook)
. improved length calculations to maximize graph width
. a proper response to platforms with less than 8 cpus
. more consistency and readability with one blank line
Signed-off-by: Jim Warner <james.warner@comcast.net>
Well, here it is. This is what the preceding series of
commits was leading to: an ability to show up to eight
cpus per Summary Area line. In reality, a self imposed
limit of four cpus on such lines seems more realistic.
In any case, the new capability could also be employed
along with that '!' toggle which consolidates adjacent
cpus into a solitary graph. When used together the '4'
and '!' toggles should accommodate any number of cpus.
Signed-off-by: Jim Warner <james.warner@comcast.net>
I guess the cat's out of the bag with the prior commit
message. It mentioned the objective of displaying more
than the current two cpu graphs on summary area lines.
On the way to that objective, this patch just prepares
our battlefield for the actual implementation in which
up to 8 individual cpu graphs will be shown on 1 line.
[ no logic has been impacted with this commit. we're ]
[ just adding one manifest constant, trading several ]
[ identifiers and updating some comments so the next ]
[ commit might be just a little bit more manageable. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This program has always been sensitive to the width of
a terminal/console. The detailed cpu/memory statistics
plus all of those full screen replacement windows were
designed to fit within some 80 column, 24 row display.
When a user narrowed a gui terminal to less than those
dimensions, top would simply truncate the data to fit.
However, when displaying cpu/mem graphs instead of the
detailed statistics such truncation was not justified.
After all, such graphs were already scaled to 80 cols.
Henceforth, when in graph mode, truncation won't occur
until the graphs will no longer fit within 10 columns.
[ can you keep a secret? this change is really being ]
[ made in anticipation of showing more than just two ]
[ cpu graphs in the summary area on each screen row! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The logic (illogic?) in the sum_tics() and do_memory()
functions has grown to become almost unfathomable over
time. Additionally, though perhaps not apparent in the
code, many steps are duplicated within those routines.
So, this patch refactors all the summary graph support
to consolidate duplicated code and (hopefully) make it
more understandable with an eye to future maintenance.
[ additionally, that show_special guy's workload has ]
[ been reduced by eliminating any special directives ]
[ previously embedded in some cpu graphs even though ]
[ a cpu may have been idle during the last interval. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When 2 abreast cpu display was introduced, the minimum
screen width was 160 columns so as to avoid (minimize)
truncation. Later that was reduced to 80 columns while
keeping the original minimum as a compile conditional.
In preparation for (virtually) eliminating these width
restrictions in a future patch this #define's history.
Reference(s):
. May, 2020 - introduced #define TOG4_NOTRUNC
commit be3dcaa842
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
When two abreast display was introduce, in that commit
shown below, this #define provision was also added. It
actually was an artifact left from program development
and never made much sense in a real world application.
If activated it would make the '4' toggle appear to be
broken since it would only take affect if a user first
activated individual cpu display (the '1' toggle off).
And there was no error message offered to those users.
So, this questionable #define is now being eliminated.
Reference(s):
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
When top was made more responsive to keyboard input in
that commit referenced below, his previous response to
a SIGWINCH was upset. Formerly, that display integrity
was restored with the next refresh cycle. But, without
this patch, one must strike some key to accomplish it.
[ in truth, this patch vastly improves that sigwinch ]
[ response. whereas before, although integrity would ]
[ be restored automatically, it did not happen until ]
[ the next regular refresh. now it is instantaneous! ]
Reference(s):
. May, 2022 - made more responsive to kdb input
commit 3ea1bc779f
Signed-off-by: Jim Warner <james.warner@comcast.net>
Thanks to valgrind and his --track-origins=yes option,
the problem and solution was suggested as shown below.
[ and it was created in that commit referenced below ]
But, after attacking this problem by adding a memset()
call in pids.c, a 2nd valgrind oops, also shown below,
was encountered. The dynamically acquired 'cmd' again!
[ might help to explain why changes appear excessive ]
Reference(s):
. 1st valgrind discovery
==11111== Conditional jump or move depends on uninitialised value(s)
==11111== at 0x13425D: stat2proc (readproc.c:582)
==11111== by 0x137436: look_up_our_self (readproc.c:1613)
==11111== by 0x132196: fatal_proc_unmounted (pids.c:1388)
==11111== by 0x11BA4D: before (top.c:3580)
==11111== by 0x127E10: main (top.c:7173)
==11111== Uninitialised value was created by a stack allocation
==11111== at 0x132165: fatal_proc_unmounted (pids.c:1381)
. Jul, 2022 - fatal_proc_unmounted refactored
commit 52bd019d8c
. 2nd valgrind discovery
==22222== 16 bytes in 1 blocks are definitely lost
==22222== by 0x4A0E60E: strdup (strdup.c:42)
==22222== by 0x133D00: stat2proc (readproc.c:587)
==22222== by 0x136E67: look_up_our_self (readproc.c:1613)
==22222== by 0x131BC7: fatal_proc_unmounted (pids.c:1390)
==22222== by 0x11B7C6: before (top.c:3580)
==22222== by 0x127828: main (top.c:7173)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Turn on trace() with the TRACE macro and remove the ## token paste
preprocessor operator which is unnecessary here and causes these errors:
ps/common.h:176:26: error: pasting "(" and ""ps_argv[thisarg] is %s\n""
does no t give a valid preprocessing token
.
Send trace output to STDERR.
Tracing can be enabled by adding TRACE to CPPFLAGS as follows:
./configure CPPFLAGS="-DTRACE"
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
pgrep and friends naturally filter their own processes from their
matches. The same issue can occur when elevating with tools like sudo or
doas, where the elevating shim layers linger as a parent and are
returned in the results. For example:
% sudo pkill -9 -cf someelevatedcmdline
1
zsh: killed sudo pkill -9 -cf someelevatedcmdline
This is a situation we've actually seen in production, where some poor
soul changes how permission management works (for example with Linux's
hidepid option), needs to elevate a pgrep or pkill call, and now ends up
with more than they bargained for. Even after the issue is noticed,
resolving it requires reinventing some of the pgrep logic, which is
unfortunate.
This commit adds the -A/--ignore-ancestors option which excludes pgrep's
ancestors from the results:
% sudo ./pkill -9 -Acf someelevatedcmdline
0
We looks at multiple layers of the process hierarchy because, while
things like sudo only have one layer of shimming, some mechanisms (like
those found in a typical container manager like those found in Docker or
Kubernetes) may have many more.
Signed-off-by: Chris Down <chris@chrisdown.name>
This commit addresses a potentially disastrous flaw in
that fatal_proc_unmounted() function wherein requested
item(s) might not have been returned to the caller yet
were specified at the time of a 'new' or 'reset' call.
The root cause, uncovered by Craig, was due to the old
library look_up_our_self() support function which only
would populate a proc_t with limited 'stat' file data.
This routine will now act the same as all other <pids>
functions which return a stack or stacks. Whatever was
specified with a 'new' or 'reset' will be returned, if
the passed 'return_self' parameter is other than zero.
[ as is so often the case, when flawed code is fixed ]
[ former complexity can be reduced as a side benefit ]
Reference(s):
https://www.freelists.org/post/procps/issue-245-plus-one,2
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the next commit the fatal_proc_unmounted function
will be refactored to behave as it always should have.
So, a need for the user 'stat' caution will disappear.
Reference(s):
. original man page change
commit 7d44c94317
Signed-off-by: Jim Warner <james.warner@comcast.net>
Gosh this particular flaw originated way back in 2015.
[ that was when we burdened a caller with additional ]
[ responsibilities for 'stacks_alloc', 'stacks_fill' ]
[ and 'stacks_dealloc'. damn implementation details. ]
Reference(s):
. Aug, 2015 - introduced<pids> api
commit 7e6a371d8a
Signed-off-by: Jim Warner <james.warner@comcast.net>
Discovered this while trying to port programs that use the deleted
libprocps function look_up_our_self() which can be found with the
fatal_proc_unmounted() function.
While procps_pids_new() will allow you to specify any items you
care to think of, a subsequent call to fatal_proc_unmounted()
will only fill in the values found in /proc/self/stat.
Added a caveat to the procps_pids manpage pointing out this
limitation.
References:
https://salsa.debian.org/xorg-team/app/apitrace/-/blob/debian-unstable/lib/os/os_memory.hpp#L44https://gitlab.com/-/snippets/2377884
Signed-off-by: Craig Small <csmall@dropbear.xyz>
In that issue cited below, Tyson Nottingham identified
a potential abend which was associated with 'alternate
display mode' plus that troublesome 'mkVIZrow1' macro.
He also offered a perfectly adequate fix for that bug.
I refer to that macro as troublesome since it's now so
widely used and sometimes (by design) causes 'begtask'
to go negative (invalid). And now I found yet one more
place where it should have been used but wasn't ('f').
It's also troublesome as evidenced by some git history
listed below. Heck, there was even a commit addressing
the same symptoms (alternate display mode abend) which
Tyson suffered. Clearly, the current design is flawed.
So, with those two issues in mind, I've refactored the
approach to maintaining a visible task in the 1st row.
Henceforth, a 'mkVIZrow1' macro will be issued in only
two places: once at startup and after most keystrokes.
Such an approach likely results in additional calls to
the 'window_hlp' routine that aren't really necessary.
But, it provides a cleaner design less prone to errors
in the future. Besides, such additional overhead would
only be incurred when interacting with the user. Thus,
new costs are of no concern and will never be noticed.
Reference(s):
. Tyson Nottingham reported problem
https://gitlab.com/procps-ng/procps/-/issues/245
. Jun, 2018 - visible row 1 tasks first addressed
commit 6aedeac667
. Jun, 2018 - adressed edge case, new bugs created
commit 9d59ddc466
. Sep, 2018 - additional edge case addressed
commit 59f02f19c7
. May, 2021 - some abends fixed, new error created
commit 8281ac4f98
. Jun, 2021 - try to prorect against future errors
commit 2ea082b4af
. Sep, 2021 - integrate mkVIZ & 'focused' tasks
commit 69978e3650
Discovered by: Tyson Nottingham
Signed-off-by: Jim Warner <james.warner@comcast.net>
Use of the the '.B' and '.BI' man documentation macros
had rendered the three library API pages less readable
than they could be. In addition, sometimes the pointer
indicator and an identifier were separated by a space.
So, this commit will trade those macros for some '.RI'
and '.RB' macros plus treat the pointers consistently.
[ plus we no longer italicize sort 'stacks' brackets ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
If procps is built on a Linux 5.3+ system then pidwait
is built with pidfd_open(). If that program is run on
a system < 5.3 then it gives an odd generic error.
If we get a ENOSYS from one pid, we will get it for all
the others so its better to explain what happens and terminate.
The man page is updated to note this issue.
This came up due to killall in psmisc using pidfd_send_signal
References:
https://bugs.debian.org/1015228
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Using localtime() can be a problem due to the static buffer for
the return value. It's simple enough to use localtime_r()
Signed-off-by: Craig Small <csmall@dropbear.xyz>
If we're deleting a character or operating in overtype
mode, we must account for the potential of 'invisible'
characters. When one follows any character about to be
deleted or replaced both multi-byte sequences must go.
Without this change, there exists the possibility that
top might report some error where no error is apparent
to the user. For example, with 'other filtering' (o/O)
the user could see "unrecognized field name 'COMMAND'"
where the quoted column name appears perfectly normal.
Or maybe a sequences like the 'combining acute accent'
gets applied to an existing character instead of being
deleted as one expects when its parent was eliminated.
So, henceforth whenever any character is being deleted
we will now check for a following 'invisible' sequence
then eliminate it along with that preceding character.
[ admittedly, these scenarios are very rare yet they ]
[ may occur, especially when recalling some previous ]
[ multi-byte strings for editing. and, since we will ]
[ be interacting with a user, performance won't be a ]
[ factor so extra checks for a zero wcwidth is fine. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
