If a hash results report was output (via ATEOJ_RPTHSH)
a portion is devoted to occupied table entries ordered
by depth. There is a possibility that some depths will
not be found among existing occupied table entries and
to avoid any confusion probably should not be printed.
[ to illustrate the potential for confusion prior to ]
[ this patch, force a very small table size (like 8) ]
[ and then arrange to trigger the end-of-job report. ]
So this patch ensures only 'in use' entries are shown.
[ admittedly, all of the remaining logic in the loop ]
[ could/should be subordinate to this new 'if' test, ]
[ but we will keep the change to a minimum. besides, ]
[ there's no harm subtracting/adding a zero numdepth ]
[ especially since the chance of a zero is very low. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just raises the size of the hash table used
to calculate elapsed task stuff. The net result should
be less need for 'chaining' under pid hash collisions.
[ the hash scheme is intentionally kept as primitive ]
[ and, therefore, as fast as possible. it employs an ]
[ 'and' approach versus a 'mod' operation since both ]
[ yield similar distribution but the former approach ]
[ was 4 fewer cpu instructions in terms of overhead. ]
[ additionally, for hash collisions, 'chaining' uses ]
[ an array index rather than the usual pointer since ]
[ the HST_t guys may move when they are reallocated. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is an outgrowth of that commit shown below.
Many additional potential segmentation faults might be
encountered if interactive commands are opened up to a
user when a '-p' switch has a single non-existent pid.
[ always the 'k', 'L', 'r', 'Y' keys & maybe 'v' too ]
So, this patch will restrict such a loser (oops, user)
to a reduced subset of normal commands until he/she/it
quits then restarts top with something to be displayed
or issues the '=' command overriding that '-p' switch.
Reference(s):
commit f57a0301e3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch fixes a nearly decade old bug discovered by
Frederik Deweerdt. His merge request shown below would
be an adequate solution except for iterative overhead.
This alternate patch will represent substantially less
overhead for an admittedly extremely rare possibility.
Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/114
And-thanks-to: Frederik Deweerdt <fdeweerdt@fastly.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ this is what happens when i've run out of bugs and ]
[ issues and am now left with way too much free time ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
All of these changes are self-explanatory, so I'll not
provide any more comments thus avoiding further shame.
[ everything's perfectly justified and right margins ]
[ are filled entirely, but of course it must be luck ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit only eliminates two 'nop' instructions and
one 'jmp' instruction. However, it makes that C source
code look a little bit prettier than it looked before.
[ and yes, some unnecessary parenthesis were used to ]
[ force an alignment of some related lines. it costs ]
[ us nothing in extra code yet helps in readability. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch eliminates one variable which resulted in a
corresponding elimination of three 'mov' instructions.
[ that was 6 bytes per 'mov' for a total of 18 bytes ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
We won't go as far as the merge request shown below in
increasing buffer size, but we'll reduce substantially
total iterations while growing it to achieve one read.
[ and this seems in line with what was recently done ]
[ to accommodate the massively parallel environments ]
[ thru 2 abreast ('4') and combined cpus ('!') modes ]
Reference(s:
https://gitlab.com/procps-ng/procps/-/merge_requests/105
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is prompted by the preceding change to the
library's escape.c module which, in turn, was prompted
by that issue shown below (with thanks to Konstantin).
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/176
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've grown to hate that man document rendering when it
comes to hyphenation. So this patch will eliminate it.
And we'll also eliminate an unnecessary initialization
in that top program code concerned with combined cpus.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This ensures that a single '4' keystroke will reliably
toggle the new 2 abreast mode ON. Depending on whether
an older configuration file existed or whether top was
configured with '--disable-modern-top', keying the '4'
for a second time might otherwise have been necessary.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous PRETEND8CPUS #define was recently changed
to PRETEND48CPU to better exercise the new '4' and '!'
toggles. But, the implementation simply duplicated the
/proc/stat summary line for each cpu. Therefore, every
cpu showed the same graph/detail (depending upon 't').
This patch shows the actual individual cpu information
(duplicated, of course, when total cpus are exceeded).
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will address Craig's feedback regarding the
original implementation of top's two new toggles. It's
likely other users would have questioned why they were
not saved also, once they discover these new features.
And, since the minimum terminal width was just lowered
to 80 columns, the default for window #1 is also being
changed to show the individual cpu graphs two abreast.
[ assuming no '--disable-modern-top' for ./configure ]
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172https://www.freelists.org/post/procps/two-major-changes-to-top,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm about to break older top rcfile compatibility when
preserving those two new toggles. And, though this has
happened several times over the years, we never issued
any warnings that such thing was just about to happen.
So, this patch corrects the long standing shortcoming.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For the original implementation of the '4' toggle, the
minimum width was set at 165 columns. This was done to
avoid truncations when detailed cpu statistics (versus
graphs) were being displayed. Those can not be scaled.
Upon reflection, it seems more appropriate to give the
user the choice of whether or not to truncate. And, by
reducing that minimum width requirement to 80 columns,
we'll vastly expand potential use of two abreast mode.
[ we'll keep that original as '#define TOG4_NOTRUNC' ]
The patch also updates the man document appropriately.
Along the way, we will trade the potentially confusing
word 'adjacent' for the more natural 'additional' when
detailing the '!' toggle in 4b. Summary-Area-Commands.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172https://www.freelists.org/post/procps/two-major-changes-to-top
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch attempts to supress the following warnings:
. MISSING_BREAK, TAINTED_SCALAR plus SIZEOF_MISMATCH .
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch simply allows for better testing of our two
new toggles: '4' (2 abreast) plus '!' (combined cpus).
Signed-off-by: Jim Warner <james.warner@comcast.net>
When implementing that earlier '4' toggle, in response
to the issue referenced below, I got to thinking about
those environments with massively parallel processors.
Such environments may not benefit from the '4' toggle.
So, I decided to implement a feature that could enable
use of those '1' and/or '4' toggles no matter how many
active processors top may have ultimately encountered.
With the new '!' toggle, adjacent cpus can be combined
to any degree, represented as a single cpu group/line.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the back of my mind, I've always wanted to enable a
two abreast cpu display. Folks with massively parallel
machines must surely have been frustrated with the '1'
toggle when Off (individual cpus in the Summary Area).
So, I'll use that recently raised issue shown below as
a justification for finally implementing this feature.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
Several years after the 'e' & 'E' interactive commands
were introduce to affect memory scaling, an 'E' switch
was added. This was after discovering a dropped Redhat
patch which provided a unique 'M' command line switch.
If only for symmetry it makes sense to offer a similar
command switch ('e') for the Task Area memory scaling.
As was true with 'E', top's help text will show 'e' as
if it were a switch without arguments in order to keep
help text displayed without wrap in an 80x24 terminal.
The man page, however, will show all of the arguments.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/165
. 03/2017, added 'E' command line switch
commit fb48b5d9fb
. 12/2012, added 'e' interactive command
commit 21e550bc08
. 12/2012, added 'E' interactive command
commit bc46f67f9a
Signed-off-by: Jim Warner <james.warner@comcast.net>
The Debian bug referenced below has nothing to do with
locales. In fact, top was made locale independent back
in release 3.3.13 (April, 2018). However, that bug did
reveal some misplaced logic which this patch corrects.
Prompted by the Qualys audit, all rcfile field strings
were checked for potential duplicates which could only
have resulted from some user's manual/malicious edits.
Unfortunately, that code was executed before top had a
chance to enforce the proper/maximum string length (in
the event an extremely old rcfile had just been read).
This created some potential string overrun references.
In top's original 3.3.15 implementation, the potential
overrun extended for 15 characters. That is the number
of field characters added with 3.3.9 (December, 2013).
But, since strchr() was used, no error exit was taken.
In the revised 3.3.16 implementation, the strchr() was
replaced with '&w->rc.fieldscur[n]'. This held overrun
to a single position while producing an error message.
So, this commit just moves that logic to a point where
fieldscur is guaranteed to be longer than EU_MAXPFLGS.
Reference(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951335
. revised 3.3.16 validation logic
commit 291d98ee50
. original 3.3.15 validation logic
commit fdb58974e2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When that potential abend at program end was addressed
in the patch shown below, one line of code was removed
in error. That line served to suppress some end-of-job
reports should ATEOJ_RPTSTD or ATEOJ_RPTHSH be active.
So, this patch restores that previously deleted logic.
Reference(s):
. potential SEGV fix, master branch
commit d37f85c269
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit 0847390b83
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit duplicates a change to that newlib branch.
However, it should be noted that such a change was not
really necessary under this master branch since proc_t
data remains valid much longer. It is being duplicated
here as documentation only. Below is the original msg.
------------------------------------------------------
This patch will eliminate a bug which is unique to our
newlib branch. It's extremely rare and only happens if
a search ('L'/'&') is initiated during the period when
fields are currently being auto-sized (AUTOX_MODE on).
This bug surfaces as either all zero results for tasks
displayed or a segmentation fault, depending upon what
fields were activated. It is caused by the timing of a
call to the <pids> 'reset' function. When called after
a task refresh, but before do_key(), this bug appears.
So this patch just ensures that 'reset' will be called
after do_key() & before the tasks have been refreshed.
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beyond the copyrights, the single oops in the man page
was introduced in the commit which is referenced below
dealing with some cleanup following that Qualys audit.
Reference(s):
. man page error introduced
commit e531c78140
Signed-off-by: Jim Warner <james.warner@comcast.net>
The backtrace shown in the bug report referenced below
illustrates a 'normal' program termination interrupted
with some signal, ultimately then causing a top crash.
So this commit just rearranges a little code such that
all signals will be blocked during that rather lengthy
end of program processing regardless of how initiated.
[ in that report, ignore the assertion regarding the ]
[ '-n' option. it obviously was not '1' since do_key ]
[ had been called, which otherwise wouldn't be true. ]
[ and when it is '1' the -d option would be ignored. ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1737552
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit most significant change is the elimination
of the kbd_ENTER entry from that tinfo_tab in iokey().
That entry was a useless artifact left from the commit
which is shown below. It makes no sense to 'translate'
a keystroke into something it already was (i.e. '\n').
The remaining changes just reorder those table entries
for a progression consistent with vim keys: h,j,k & l.
Reference(s):
. fix 'iokey()' flaw preventing proper translations
commit 42f0a341ba
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit standardizes the behavior of the PgUp/PgDn
keys when on the main top display. With PgDn, the last
process will become the first process. With PgUp, that
first task will now appear as the last task displayed.
[ this also eliminates some quirks that were evident ]
[ when paging at or near the end of the process list ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent issue (and merge request) reminded me of gaps
in top's alternate 'vim' navigation keys support. Some
xterm emulators do not pass the customary strings when
keys were used with the <Ctrl> and/or <Alt> modifiers.
While it was a known problem, this issue/merge request
prompted research into the root cause. As it turns out
the problem is traceable to an X resource known by the
name 'eightBitInput'. When 'true' (the default), a key
pressed in combination with <Alt> will not be preceded
by the <Esc> character. Rather, a single character was
presented (modified via an 'eightBitMeta' X resource).
The following approaches would eliminate this problem:
. start xterm thus: xterm -xrm '*eightBitInput: false'
. use: ~/.Xresources with 'Xterm*eightBitInput: false'
. build xterm with 'configure --enable-meta-sends-esc'
( apparently used for CentOS, Fedora, openSUSE, etc. )
. enable xterm's menu via 'configure --enable-toolbar'
( so the user can set the 'Meta Sends Escape' option )
Of course, none of the above steps is desirable from a
user's perspective. So, this patch will add additional
entries to the iokey function's tinfo_tab to represent
strings passed when the <Alt> key does not send <Esc>.
[ hopefully they'll be the same across all platforms ]
Lastly, this patch will also eliminate those redundant
<Atl> + '\', '/', '<' & '>' provisions, which now seem
like overkill and suffer from that same 'eightBitMeta'
xterm problem. And we might as well say goodbye to the
4 '<Alt> + arrow key' table entries (which do not seem
to currently work with any emulator which I can find).
[ what in the world was I thinking way back in 2011? ]
Reference(s):
. issue
https://gitlab.com/procps-ng/procps/issues/135
. merge request
https://gitlab.com/procps-ng/procps/merge_requests/84
Signed-off-by: Jim Warner <james.warner@comcast.net>
I thank Guido Jäkel for raising the issue cited in the
merge request referenced below. While restoring 1 line
of code would produce the desired results, it does not
address the root cause of that problem he experienced.
The variable 'smp_num_cpus' was set by libprocps via a
sysconf(_SC_NPROCESSORS_ONLN) call. It was supposed to
represent total number of processors currently online.
It also served as the position in the Cpu_tics[] array
where the /proc/stat line #1 (cpu summary) was stored.
The variable 'Cpu_faux_tot' was valued by top based on
total individual cpus parsed from the /proc/stat file.
It serves as a fence post for Cpu_tics[] array access.
The problem Guido experienced results from a disparity
between those 2 variables, plus one instance where the
wrong variable was used in the summary_show() routine.
. Here is the real culprit, the actual incorrect code:
. summary_hlp(&Cpu_tics[Cpu_faux_tot], N_txt(WORD_a...
Which always should have been represented in this way:
. summary_hlp(&Cpu_tics[smp_num_cpus], N_txt(WORD_a...
------------------------------------------------------
The above 'disparity' might arise in any system when a
cpu is taken offline since there's a 3 second delay in
cpu and memory refreshes in an effort to reduce costs.
Usually this particular condition will be short lived.
However, there is a more persistent problem under lxc.
If a host cpu is taken offline and then brought online
again, within the container sysconf returns the proper
number of online processors. But, /proc/stat does not!
Sadly, I've yet to find a way to coax a container into
refreshing its /proc/stat, short of reboting the host.
[ might that represent a potential bug in lxc logic? ]
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/82
Signed-off-by: Jim Warner <james.warner@comcast.net>
With-thanks-to: Guido Jäkel <G.Jaekel@DNB.DE>
While setting the size of that Hide_pid array to equal
total pids high water mark was probably safe, in truth
there is no real relationship. At some point one could
exceed that HWM if the 'v' toggle was used extensively
and at least 1 of those entries remained non-negative.
This commit simply divorces Hide_tot from the pids HWM
and bases Hide_pid array size on actual run-time need.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Currently, except for tasks that have no parents, when
a process' children are collapsed the '+' indicator is
shown in the first position within that COMMAND field.
This commit simply provides for indenting the '+' char
so it displays next to that program name/command line.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In that commit referenced below, a few edge cases were
addressed regarding vertical positioning involving any
'hidden' tasks. But, 2 additional edge cases remained.
In a running top, if the user employed 'other filters'
(o/O) or 'user filters' (u/U) proper vertical position
was not ensured. And, while this could be easily fixed
by striking the home/end or up/down arrow keys, it was
very poor etiquette to shift this burden to the users.
So, this patch plugs that gap, automating the process.
Reference(s):
commit c6e68e2fed
Signed-off-by: Jim Warner <james.warner@comcast.net>
From the outset, top has tried to provide some minimal
garbage collection in support of forest view collapse.
For example, with every 'v' keystroke, a check is made
of the currently targeted pids. If all were negative,
which means expanded, that Hide_pid array was emptied.
Recently, yet another efficiency was added wherein the
continuing scan for a targeted pid was terminated when
a match was found. But, one more inefficiency existed.
When a task which was subject to collapse under forest
view mode has disappeared (ended), repeatedly scanning
for such a pid with each iteration makes little sense.
So this commit will negate such targeted pids and thus
avoid scanning every current task looking for a match.
Then, if 'v' is ever stuck at some point in the future
there will be a chance to empty that Hide_pid[] array.
[ hopefully this will be a final tweak of the forest ]
[ view collapse stuff, but cross your fingers anyway ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Our newlib branch has already dropped support for such
old kernels. However, the master branch still supports
them. So this patch will correct a broken #define that
is used to influence the top Summary Area information.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In forest view mode, once a collapsible parent process
and all of its children (if any) have been identified,
there is no longer a need to scan the remaining tasks.
So this patch will just force a new scan for any other
'Hide_pid' entries which might remain to be identified
after a targeted parent has been completely processed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch includes the following miscellaneous stuff:
. ensure 1 space before any '*' ptr sizeof() reference
. explain the rather cryptic 'ioa' guy a little better
Signed-off-by: Jim Warner <james.warner@comcast.net>
Currently, it isn't possible to establish an 'Inspect'
pipe that relies on SIGINT to end. That's because this
signal will also end the parent process (top) as well.
So this patch will temporarily ignore that signal when
processing any 'Inspect' pipe, allowing one like this:
. pipe ^I Trace Calls ^I /usr/bin/strace -r -p %d 2>&1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Upon startup there exists the potential for some minor
memory leakage should some rcfile 'Inspect' entries be
invalid. By delaying any malloc/strdup until after the
entries are completely validated we will prevent that.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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
