Parent tasks with collapsed children should have their
cpu reflect any unseen tasks only under the following:
1) When built without TREE_VCPUOFF having been defined
2) Exclusively when 'Show_FOREST' display mode was set
3) And only under the current window when in alternate
display mode (except if TREE_VWINALL has been defined)
So, this commit just ensures these objectives are met.
Reference(s):
. issue that began odyssey
https://gitlab.com/procps-ng/procps/issues/99
. original cpu implementation
commit 3da7318683
Signed-off-by: Jim Warner <james.warner@comcast.net>
While that 'Hide_cpu' value will always be zero unless
there are collapsed children, the damn array will only
be present when a window's in 'Show_FOREST' view mode.
Reference(s):
https://www.freelists.org/post/procps/important-improvements-to-top,8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Using Ctrl-V for the collapse children key now appears
as a mistake. First, it's too close to that Ctrl-C key
which would prematurely terminate top. Second, a lower
case 'v' was unused and perfectly compliments an upper
case 'V' which is used to toggle 'forest view' itself.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just addresses these miscellaneous issues:
. always use 'p' for pointers to that proc_t structure
. always match order of local #undef to parent #define
. forest_create use of array index made more efficient
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now, when a parent's children have been collapsed, the
cpu used by those unseen tasks will disappear no more.
Instead such tics will be added to the parent's total.
[ if one wished a return to the 'land of lost tics', ]
[ the '#define TREE_VCPUOFF' directive is available. ]
------------------------------------------------------
Note: With collapsible parents now displaying children
cpu usage, it will eventually be noticed the cpu stats
for the summary area and task areas often vary widely.
It's worth a reminder that for top's summary area each
individual cpu and the cpu summary is limited to 100%,
regardless of how many tics a linux kernel may export.
An individual task is limited to 100% times the number
of threads. But, in no case will cpu usage ever exceed
100% times total number of processors. Such limits are
further reduced under 'Solaris' mode ('I' toggle off).
In this mode, a task cpu usage will never exceed 100%.
These limits will now also apply to collapsed parents.
In addition to those influences, results are subjected
to kernel timer sampling anomalies and the distortions
inherent in a small sample size, made worse by smaller
delay intervals. Often there is just 1 or 2 tics for a
few tasks at smaller intervals such as: 1/10th second.
Anyway, should questions on this subject arise, a good
starting point, beyond the reminders above, is the 1st
link listed below. Those other links were derivatives.
Reference(s):
. from the kernel documentation
https://www.kernel.org/doc/Documentation/cpu-load.txt
. as mentioned in the above kernel documentation
https://lkml.org/lkml/2007/2/12/6
. from above, with many more links on the subject
https://www.boblycat.org/~malc/apc/
Signed-off-by: Jim Warner <james.warner@comcast.net>
top: parent total cpu includes collapsed children, pgm
So that the impact (minimal) of the next commit can be
isolated, this commit just involves a little renaming,
reformat plus a refactor of some proc_t pointer logic.
[ renaming, relocation and changes to 'user_matched' ]
[ wasn't strictly necessary, but now mirrors newlib. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just addresses some edge cases with respect
to 'unseen' tasks. Given the ability to preserve other
filters in the rcfile, it's entirely possible the very
first task(s) may not be visible at top startup. Also,
when switching between windows ('a'/'w') we should try
to always position its row #1 on some visible process.
Lastly, a window might have *NO* visible tasks at all.
Therefore, protect 'window_hlp' from an infinite loop.
Signed-off-by: Jim Warner <james.warner@comcast.net>
GitLab now has a separate spot for build status badges outside the
README.
References:
procps-ng/procps#95
Signed-off-by: Craig Small <csmall@enc.com.au>
Inspection of vmstat.c and experimentation with the binary itself
both confirm that the units of the swap (si/so) fields are
controlled by the --unit option.
References:
procps-ng/procps!69procps-ng/procps#100
Signed-off-by: Craig Small <csmall@enc.com.au>
To my knowledge, nobody has ever complained about some
anomalies when scrolling vertically if tasks should be
hidden from view. This can happen with the user filter
('u/U') or other filter ('o/O') features. And although
some tasks are not shown, they still impact scrolling.
This is most apparent when that scroll coordinates msg
is on ('C') & up/down arrow keys used (vs. pgup/pgdn).
Now that we can collapse/expand forked children, there
is a potential for yet more of those hidden processes.
So this commit normalizes vertical scrolling providing
an expected behavior. In other words, the up/down keys
skip the unseen tasks to reposition on a visible task.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is simply preparation for upcoming vertical
scrolling enhancements. With those changes, it will be
impossible to predict what the beginning task position
should be at the time the message is currently issued.
This patch will allow such a message to be shown after
the individual windows' tasks have all been displayed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The issue cited below really dealt with preserving the
'Other filter' criteria in the rcfile. But as an aside
the htop 'F6' feature (collapsed children) was raised.
I took that as an implied challenge and decided to try
implementing a similar feature in top. So, this commit
will now provide a brand new forest view toggle ('^V')
which will be used to collapse/expand forked children.
[ this patch will also lead to additional patches in ]
[ support of more rational vertical scrolling, since ]
[ many more tasks might now be hidden in some window ]
Reference(s):
. where this secondary issue was raised
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
In anticipation of a new collapsible child feature, we
will have to make some forest view variables available
to that 'keys_task()' function. This commit just moves
the forest view logic ahead of tertiary input support.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Well, after the rearranging and refactoring, all those
active 'other filter' entries for each window will now
be preserved in the user's configuration file via 'W'.
For raising the issue below, thanks to Marco Ippolito.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
These modifications are being made now in anticipation
of some coming 'other filter' config file changes. Our
entries must be written last to the rc file since that
is where the users have been told to 'echo' additions.
Therefore, that 'config_insp' function must be adapted
to anticipate a passed buffer that was already primed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
If we are to support preserving 'other filter' entries
in the rcfile, then the current logic setting up those
osel entries for a WIN_t must be shareable for startup
and when interacting with a user. So, this commit just
repositions this current code in a shareable function.
[ along the way, we give the prior guy a proper name ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When we get around to saving that 'Other Filter' stuff
in the rcfile, we'll need access to the Fieldstab plus
the justify_pad() function. So this commit repositions
two 'osel' functions in anticipation of adding 1 more.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'config_file()' function was getting a little long
in the tooth, so this commit simply renames/rearranges
some stuff anticipating 'other filters' in the rcfile.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jeeze, there was no need to employ *both* strchr() and
strrchr() when ensuring fields hadn't been duplicated.
So let's avoid one of those function calls completely.
Signed-off-by: Jim Warner <james.warner@comcast.net>
We now use the actual terminfo 'max_colors' value with
the 'color mapping' screen, not that hard coded '256'.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/96
. introduced 256 color support
commit cf057d2fe5
Signed-off-by: Jim Warner <james.warner@comcast.net>
When not displaying all tasks (the 'i' toggle is off),
the concept of vertical scrolling has no real meaning.
However, only 2 keys (up/down) impacting that vertical
position were currently being disabled with this mode.
This patch will extend such treatment to the following
additional vertical impact keys: pgup,pgdn,home & end.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This program does a good job of policing that vertical
scrolled position, ensuring that total tasks are never
exceeded. However, during transitions from thread mode
to normal task mode (the 'H' toggle) that wasn't true.
And while there was no real harm done, it did make the
use of up/down arrow keys "appear" disabled especially
if that scroll message was not displayed ('C' toggle).
This patch simply forces a return to row #1 whenever a
user toggles that display between thread & task modes.
Signed-off-by: Jim Warner <james.warner@comcast.net>
As it turns out, the very first entry in the 'iokey()'
tinfo_tab was preventing the proper translation of the
simulated PgUp/PgDn keys (ctrl+meta+k/j). Ignoring the
tortured history behind the most recent change to that
entry, this patch restores the previous value and once
again properly translates these particular keystrokes.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The current checks allow out-of-range values (for example, if
getenv/atoi returns ~-2GB, maxcmd becomes ~+2GB after the subtraction).
This is not a security problem, none of this is under an attacker's
control.
With the Qualys security audit, we began to harden our
treatment of the top rcfile. In particular, the values
read were checked so as to prevent some malicious user
from editing it in order to achieve an evil objective.
However when it came to colors I was surprised to find
that at least one user edited the rcfile for 256-color
support. Unfortunately, our new checks prevented this.
So this commit will provide the means to exploit those
extra colors with no need to manually edit the rcfile.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/96
Signed-off-by: Jim Warner <james.warner@comcast.net>
It's good that those Qualys folks were looking over my
shoulder. They suggested a change to that commit shown
below. This improvement was obviously a better choice.
Reference(s):
. original change
commit f9a8009e27
Signed-off-by: Jim Warner <james.warner@comcast.net>
Following that patch referenced below, the top SUPGRPS
field would produce a segmentation fault and ps SUPGRP
would often show "(null)". Such problems resulted from
some faulty logic in the status2proc() routine dealing
with 'Groups' (supgid) which served as a source field.
For many processes the original code produced an empty
string which prevented conversion to the expected "-".
Moreover, prior to release 3.3.15 such an empty string
will become 0 after strtol() which pwcache_get_group()
translates to 'root' yielding very misleading results.
So, now we'll check for empty '/proc/#/status/Groups:'
fields & consistently provide a "-" value for callers.
[ we'll also protect against future problems in that ]
[ new qualys logic by always ensuring valid 'supgrp' ]
[ pointers - logic which revealed our original flaw! ]
Reference(s):
. original qualys patch
0071-proc-readproc.c-Harden-supgrps_from_supgids.patch
Signed-off-by: Jim Warner <james.warner@comcast.net>
The free manpage used the correct unit names (e.g. membibyte) but the
incorrect unit (e.g. M ) for the human-readable option.
References:
https://bugs.debian.org/898774
Signed-off-by: Craig Small <csmall@enc.com.au>
This guards against rcfile 'Inspect' entries which may
include non-printable characters. While this shouldn't
occur, we have no real control over those crazy users.
[ and, while such data can't be used maliciously, it ]
[ does adversely impact such a user's screen display ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When a Qualys patch was reverted as being unwarranted,
1 specific problem their patch had, in fact, prevented
was re-introduced. This patch corrects that oversight.
Reference(s):
. qualys patch revert
commit c502678715
Signed-off-by: Jim Warner <james.warner@comcast.net>
Until the Qualys security audit I had never considered
it a possibility that some malicious person might edit
the top config file to achieve some nefarious results.
And while the Qualys approach tended to concentrate on
the symptoms from such an effort, subsequent revisions
more properly concentrated on startup and that rcfile.
This commit completes those efforts with 1 more field.
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've long since forgotten why the attempt to influence
groff line lengths was made. However, I did receive an
email regarding problems formatting postscript output.
Hopefully this patch will eliminate any such problems.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The library now presents command names up to 64 characters, in line with
the kernel changes. ps command name selection (the -C option) now also
is 64 characters long.
References:
commit 2cfdbbe897
The referenced commit removed the warning for using pgrep with over
15 characters. The check for this warning needs to also be removed.
References:
commit c32ab58b94
The command name for running tasks is displayed by top
in a variable length field, so the increase from 16 to
64 bytes was not a problem. However, there's one place
where top is sensitive to length - insp_view_choice().
So, this patch just bumps a buffer used to display it.
Reference(s):
. increased 'comm' length
commit 2cfdbbe897
Signed-off-by: Jim Warner <james.warner@comcast.net>
