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
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>
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>
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>
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 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>
This will protect some remaining rcfile variables from
a possible manual editing of top's configuration file.
[ and correct two #error related boo-boos introduced ]
[ with the system default rcfile in the commit shown ]
Reference(s):
. introduced /etc/topdefaultrc
commit 3e6a208ae5
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit moves some overhead to the Batch mode path
where it's needed. And given the new 'else if' test we
can delete some now redundant logic in the other path.
Reference(s):
. original qualys patch
0117-top-Prevent-out-of-bounds-writes-in-PUFF.patch
commit 059ae8b512
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch addresses a potential (but unlikely) buffer
overflow by reducing, if necessary, a memcpy length by
3 bytes to provide for an eol '\0' and 2 unused buffer
positions which also might receive the '\0' character.
[ note to future analysis tool: just because you see ]
[ binary data being manipulated in the routine, that ]
[ doesn't mean such function was passed binary data! ]
Reference(s):
. original qualys patch
0116-top-Fix-out-of-bounds-read-write-in-show_special.patch
commit ed8f6d9cc6
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm reverting this patch to prepare for some alternate
solution. In that solution I will address point #1 but
point #2 is based on a wrong assumption. There will be
no binary data ever found in the 'glob' passed to this
show_special() function. It is now always simple text.
------------------------------------------------ original commit message
This patch fixes two problems:
1/ In the switch case 0, if sub_end is at the very end of lin[], the two
null-byte writes are off-by-two (a stack-based buffer overflow). Replace
this end-of-string "emulation" with an equivalent test on ch (and then
goto/break out of the loop).
2/ "sub_end += 2" jumps over the null-byte terminator in lin[] if the
line contains a raw (without a tilde) \001-\010 character. Detect such a
null-byte terminator and goto/break out of the loop.
Note: in the case of a raw \001-\010 character, the character at
"sub_end + 1" is never processed (it is skipped/jumped over); this is
not a security problem anymore (since 2/ was fixed), so we decided not
to change this behavior, for backward-compatibility.
------------------------------------------------------------------------
Reference(s):
. original qualys patch
0116-top-Fix-out-of-bounds-read-write-in-show_special.patch
commit ed8f6d9cc6
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whereas that original patch (since reversed) addressed
some symptoms related to manually edited config files,
this solution deals with root causes. And it goes much
beyond any single top field by protecting all of top's
fields. Henceforth, a duplicated field is not allowed.
Reference(s):
. original qualys patch
0114-top-Prevent-buffer-overflow-in-calibrate_fields.patch
commit c424a64331
Signed-off-by: Jim Warner <james.warner@comcast.net>
Here, again, we have an example of attacking a problem
by addressing the symptoms. And that assertion made in
the original commit message is true if only if someone
had manually (maliciously) edited the top config file.
So let's reverse the original patch & thus prepare for
a proper solution addressing the cause, not a symptom.
Reference(s):
. original qualys patch
0114-top-Prevent-buffer-overflow-in-calibrate_fields.patch
commit c424a64331
Signed-off-by: Jim Warner <james.warner@comcast.net>
The whole idea was to make top's 'scat' function small
and very quick, unlike that standard 'strcat' routine.
To achieve that end we ignore the potential for buffer
overruns and trust callers to provide adequate dest's.
Reference(s):
. original qualys patch
0109-top-Protect-scat-from-buffer-overflows.patch
commit 9c745975b2
Signed-off-by: Jim Warner <james.warner@comcast.net>
This is as far as we need go with respect to the issue
of integer overflow addressed in that reference below.
That patch, of course, was reversed to prepare for us.
Reference(s):
. original qualys patch
0105-top-Prevent-integer-overflows-in-procs_refresh.patch
commit 131e5e2fe6
Signed-off-by: Jim Warner <james.warner@comcast.net>
That patch referenced below is being reverted because:
. By design, no other top macro looks like a function.
Instead, they all contain some minimal capitalization.
The 'grow_by_size' macro stands out like a sore thumb.
. We would need to approach 400+ million tasks for for
the 1st addressed problem to produce integer overflow.
. And a 2nd check against SSIZE_MAX remains a mystery.
Me thinks a system on which top is running will suffer
ENOMEM before we need to worry about integer overflow.
Reference(s):
. original qualys patch
0105-top-Prevent-integer-overflows-in-procs_refresh.patch
commit 131e5e2fe6
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than validate the window's 'sortindx' each time
it was referenced (as was done in the patch below), we
now ensure the validity just once when the config file
is read. Thereafter, a running top will police bounds.
Reference(s):
. original qualys patch
0102-top-Check-sortindx.patch
commit d5b8ac7139
Signed-off-by: Jim Warner <james.warner@comcast.net>
Here's yet another example of dealing with a potential
problem at the symptom level, instead of addressing it
at the source. So, we will reverse that original patch
referenced below in preparation for a proper solution.
[ at the least, this ugly code should have used that ]
[ existing MAXTBL macro, making it a little prettier ]
Reference(s):
. original qualys patch
0102-top-Check-sortindx.patch
commit d5b8ac7139
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch replaces an original patch referenced below
which has now been reversed. We now validate variables
'graph_cpus', 'graph_mems' and 'summ_mscale' just once
at startup. Thereafter, top enforces the proper range.
[ we afford the same treatment to that 'task_mscale' ]
[ variable, which was ignored in the original patch. ]
Reference(s):
. original qualys patch
0099-top-Check-graph_cpus-graph_mems-and-summ_mscale.patch
commit cd8ba5670e
Signed-off-by: Jim Warner <james.warner@comcast.net>
The variables graph_cpus, graph_mems & summ_mscale are
all well managed in a running top. They were, however,
each vulnerable to tampering via the rcfile. So rather
than continually addressing the symptoms, we'll attack
the root cause just once at startup in the next patch.
Reference(s):
. original qualys patch
0099-top-Check-graph_cpus-graph_mems-and-summ_mscale.patch
commit cd8ba5670e
Signed-off-by: Jim Warner <james.warner@comcast.net>
While it's only documented (so far) in commit text and
an occasional email I've tried to maintain some coding
standards primarily for reference/navigation purposes.
They also served, I felt, as useful mental challenges.
Someday I will get around to formerly documenting them
but in the meantime here are the ones for this commit:
. functions are grouped into logical (i hope) sections
. functions & sections are ordered to avoid prototypes
. function names are alphabetical within every section
. all functions & sections must be referenced in top.h
This patch just attempts to honor the above standards,
while also covering this new behavior in the man page.
[ please note that the net result of these 2 patches ]
[ is simply to avoid pathname truncations should our ]
[ limit of 1024 be exceeded. they do not have a role ]
[ in solving the 'local privilege escalation' issue. ]
[ and we can never prevent a user from setting their ]
[ HOME var to a directory writable by some attacker! ]
[ the only real protection for that CVE-2018-1122 is ]
[ those soon to be enhanced rcfile integrity checks, ]
[ achieved through several of the following patches. ]
Reference(s):
. original qualys patch
0097-top-Do-not-default-to-the-cwd-in-configs_read.patch
commit b45c4803dd
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch prevents three problems:
1/ Because snprintf() returns "the number of characters (excluding the
terminating null byte) which would have been written to the final string
if enough space had been available", _eol may point past the end of _str
and write out-of-bounds (in Batch mode).
2/ _eol is never checked against _str, so "while (*(--_eol) == ' ');"
may point _eol below _str and write out-of-bounds (in Batch mode).
3/ Sanity-check Pseudo_row to protect the strcpy().
This patch fixes two problems:
1/ In the switch case 0, if sub_end is at the very end of lin[], the two
null-byte writes are off-by-two (a stack-based buffer overflow). Replace
this end-of-string "emulation" with an equivalent test on ch (and then
goto/break out of the loop).
2/ "sub_end += 2" jumps over the null-byte terminator in lin[] if the
line contains a raw (without a tilde) \001-\010 character. Detect such a
null-byte terminator and goto/break out of the loop.
Note: in the case of a raw \001-\010 character, the character at
"sub_end + 1" is never processed (it is skipped/jumped over); this is
not a security problem anymore (since 2/ was fixed), so we decided not
to change this behavior, for backward-compatibility.
- Make sure i is at least 1 before "i - 1" and "--i".
- Initialize endpflg (to 0, as it was originally, since it is static)
before the "for" loop (the "break" may leave endpflg uninitialized,
for example).
pflgsall[] can contain PFLAGSSIZ = 100 elements, each iteration of the
loop can write 3 elements to pflgsall[], and there are EU_MAXPFLGS = 58
iterations: a buffer overflow (it can be triggered via the configuration
file, for example, by filling "fieldscur" with the "sortindx" flag).
The safety of the critical function task_show() depends on the sanity of
Screen_cols. Just copy the tests on w_cols to Screen_cols (from the same
function adj_geometry()).
Several of these buffer overflows can actually be triggered (through the
configuration file for example): in config_file(), inspection_utility(),
and show_special().
The default action for SIGURG is to ignore the signal, for example.
This is very similar to the patch "ps/display.c: Always exit from
signal_handler()."
Every time sortindx is used as an index, or loaded from the
configuration file. Otherwise it leads to out-of-bounds reads and
arbitrary code execution.
Otherwise they may lead to out-of-bounds writes (snprintf() returns the
number of characters which would have been written if enough space had
been available).
Also, make sure buf is null-terminated after COLPLUSCH has been written.
Otherwise they lead to out-of-bounds reads and format-string bugs.
Since these variables are set/written to in several places (for example,
config_file()), check them in the only place where they are read/used.
Also, constify the static gtab[]s.
If the HOME environment variable is not set, or not absolute, use the
home directory returned by getpwuid(getuid()), if set and absolute
(instead of the cwd "."); otherwise, set p_home to NULL.
To keep the changes to a minimum, we rely on POSIX, which requires that
fopen() fails with ENOENT if the pathname (Rc_name) is an empty string.
This integrates well into the existing code, and makes write_rcfile()
work without a change.
Also, it makes the code in configs_read() easier to follow: only set and
use p_home if safe, and only set Rc_name if safe (in all the other cases
it is the empty string, and the fopen() calls fail). Plus, check for
snprintf() truncation (and if it happens, reset Rc_name to the empty
string).
Important note: top.1 should probably be updated, since it mentions the
fallback to the current working directory.
With a little luck, this should be the final tweak for
our support of extra wide characters. Currently, those
characters don't always display the '+' indicator when
they've been truncated. Now, it should always be seen.
[ plus it's done a tad more efficiently via snprintf ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
As it turns out, that Ukrainian 'demo' text supporting
the '=' command was 152 bytes long, up from an English
version of 80 bytes. Unfortunately, the buffer used to
format all such strings was insufficient at 128 bytes.
Depending on the width of one's terminal, some strange
result could be experienced when a multi-byte sequence
was truncated. So, this just makes that buffer bigger.
Signed-off-by: Jim Warner <james.warner@comcast.net>
After wrestling with extra wide characters, supporting
languages like zh_CN, sometimes default/minimum column
widths might force a truncation of translated headers.
So, this commit explores one way that such truncations
could be avoided. It is designed so as to have minimal
impact on existing code, ultimately affecting just one
function. But it's off by default via its own #define.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When I recently added extra wide character support for
locales like zh_CN, I didn't worry about some overhead
associated with the new calls to 'mbtowc' & 'wcwidth'.
That's because such overhead was usually incurred with
user interactions, not a normal iterative top display.
There was, however, one area where this overhead would
impact the normal iterative top mode - that's with the
Summary display. So I peeked at the glibc source code.
As it turns out, the costs of executing those 'mbtowc'
and 'wcwidth' functions were not at all insignificant.
So, this patch will avoid them in the vast majority of
instances, while still enabling extra wide characters.
Signed-off-by: Jim Warner <james.warner@comcast.net>
There is (should be) no justification for changing the
width of the percentage columns (%CPU, %MEM) depending
on the BOOST_PERCNT #define. So this patch will ensure
that both columns are fixed at their former maximum 5.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the documentation update in the commit referenced
below, we should also account for such threads as they
will already be represented in the task/thread totals.
[ and do it in a way that might avoid future changes ]
Reference(s):
commit a238a687ce
Signed-off-by: Jim Warner <james.warner@comcast.net>
Back when top was refactored to support UTF-8 encoding
it was acknowledged that languages like zh_CN were not
supported. That was because a single 'character' might
require more than a single 'column' when it's printed.
Well I've now figured out how to accommodate languages
like that. My adaptation is represented in this patch.
[ and just in case someone wishes to avoid the extra ]
[ runtime costs, a #define OFF_XTRAWIDE is included. ]
Along the way, I've cleaned up some miscellaneous code
supporting the 'Inspect' feature so that the rightmost
screen column was always used rather than being blank.
[ interestingly, my xterm & urxvt terminal emulators ]
[ are able to split extra wide characters then print ]
[ 1/2 of such graphics in the last column. the gnome ]
[ terminal emulator does not duplicate such behavior ]
[ but prints 1 extra character in same width window. ]
Reference(s):
. Sep, 2017 - original utf8 support
commit 7ef38420a4
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the new approach for startup defaults was adopted
in the reference below, a file might be left open that
technically should be closed. This situation arises in
the unlikely event the #define RCFILE_NOERR is active.
Without that #define, the program will exit early thus
rendering the open file issue moot. However, even with
that #define there was no real harm with an open file.
It simply meant a 2nd FILE struct would have been used
when, or if, the rcfile was written via a 'W' command.
Anyway, this patch ensures such a file will be closed.
Reference(s):
. Dec, 2017 - /etc/topdefaultrc introduced
commit 3e6a208ae5
Signed-off-by: Jim Warner <james.warner@comcast.net>
Those references below offer more detail regarding the
default startup changes beginning with version 3.3.10.
It is important to remember that all such changes were
supposed to impact only new users or users who had not
saved the personal config file (via that 'W' command).
However, I introduced a bug wherein the rcfile was not
fully honored. This gave the changes a bad reputation.
That bug was corrected in release 3.3.11 but the issue
of default startup options keeps resurfacing. And it's
clear there's no consensus on what should be included.
Our --disable-modern-top configure option is of little
help since it remains an all-or-nothing approach. What
we need is an answer offering unlimited customization.
So, this commit will provide distribution packagers or
system administrators with a much more flexible way to
set their own preferred startup default configuration.
A new rcfile is being introduced: '/etc/topdefaultrc',
whose format/content is the same as a personal rcfile.
Thus once a 'proper' enterprise configuration has been
established and saved via 'W', it can be copied to the
/etc/ directory. Thereafter, startup in the absence of
a saved rcfile will use that configuration as default.
Now if a distribution packager or system administrator
wishes to expose their users to some of top's advanced
capabilities they can do so gradually. Perhaps setting
up graph mode for summary area task and memory display
while retaining the %CPU sort could be tried. Or maybe
showing colors, but better customized for a particular
terminal emulator. Such possibilities are now endless.
[ in exploiting this new capability, i hope that the ]
[ other windows (alt display mode) aren't overlooked ]
Reference(s):
. Sep, 2014 - Not fully honoring rcfile bug discussed
https://www.freelists.org/post/procps/top-saved-rcfile-bug
. Oct, 2014 - Attempt to defend new startup defaults
https://bugzilla.redhat.com/show_bug.cgi?id=1153049
. Jul, 2015 - Forest vs. %CPU views discussion
https://gitlab.com/procps-ng/procps/issues/6
. Oct, 2017 - Question the use of --disable-modern-top
https://bugzilla.redhat.com/show_bug.cgi?id=1499410
. Oct, 2017 - Forest vs. %CPU views discussion again
https://www.freelists.org/post/procps/Forest-mode-by-default-in-top-seems-a-bit-strange
. Dec, 2017 - Rehash of 3.3.10 startup defaults change
https://gitlab.com/procps-ng/procps/issues/78
Signed-off-by: Jim Warner <james.warner@comcast.net>
Way back in November of 2011, the library was equipped
with an overridable error message handler function. It
was done expressly for a program like top which alters
the tty. But that support was withdrawn shortly after.
This was all done in the lead up to v3.3.2. That's the
release where NLS support was added and it represented
a hectic time. In hindsight, the changes went too far.
So this commit, in a minimal fashion, restores ability
to address a potential fatal library error. After all,
any properly behaving library would never unilaterally
subject a caller to a stderr message and then an exit.
[ when exposing 1 variable in libprocps.sym, 2 other ]
[ existing symbols were repositioned alphabetically. ]
Reference(s):
. generalized library memory provisions
commit 7126cc4491
. top exploit library memory provisions
commit 88087ec5a5
. library xalloc type functions made private
commit 2865ded64e
. restored prior top memory logic
commit 05f5deb97c
Signed-off-by: Jim Warner <james.warner@comcast.net>
After noticing that the 'uk' translation expanded what
was supposed to be a 3 line header into 5 lines, seems
appropriate to offer more guidance on max lines count.
Signed-off-by: Jim Warner <james.warner@comcast.net>
And I thought those strange characters I saw with only
certain translations in Fields Management descriptions
were resulting from my terminal emulator deficiencies.
Turns out that ol' top wasn't addressing possibilities
of such descriptions ending with multi-byte sequences.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Initially, I was going to ignore that coverity warning
CID #177876. But, since top may be running SETUID it's
best if it can be avoided instead. The fix was simple.
We'll trade the access() call for a real fopen() call.
This time-of-check-time-of-use warning should go away.
------------------------------------------------------
When XDG support was originally introduced in top, the
author made a poor choice in access(). A real question
that needed asking was 'does the file exist'. However,
the question that was asked was 'can this real user ID
or this real group ID access the file'. Then, when the
fopen() is finally issued, top would use the effective
user ID or the effective group ID to access that file.
That's what opened the potential TOCTOU vulnerability,
which was important only if top was running SUID/SGID.
Signed-off-by: Jim Warner <james.warner@comcast.net>
By eliminating the call to 'fmtmk', the 'utf8_justify'
function could more easily be used in libproc someday.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Gosh, all this time we used indents of 4 spaces, not 3
spaces which were always the top standard indentation.
[ and we made our 'utf8_embody' a little more robust ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The top man page was changed back on 10/20/15, in that
commit shown below. There, freelists.org was suggested
as the bug reports recipient. But, the program was not
changed from the original Debian bug reports approach.
Reference(s):
commit b1f7b2a509
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch better exploits short-circuit evaluation in
two 'if' tests. In every case, the 1st of 2 conditions
in each 'if' test must take place but it always proves
true with each iteration for 1 of the 'if' statements.
Thus, the 2nd condition will have to be evaluated too.
By reordering 2 tests in each 'if', we can ensure that
the 2nd condition will then be tested much less often.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Upon reflection, there was absolutely no justification
for that call to strlen() which was then followed by a
call to snprintf(). The latter provides this needed #.
[ also make that 'delta' value a little more visible ]
[ instead of hiding it at the end of a its code line ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that top can properly handle translated multi-byte
strings I've been reviewing translated efforts so far,
and weighing output against related translation hints.
In one case, a translation hint has not kept pace with
the current program state. In addition, that same hint
could be expanded to suggest translation alternatives.
[ frankly I never expected the translators to tackle ]
[ some of those 'special' strings. the task appeared ]
[ just too daunting. but they have done a great job! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the help of our Swedish translator, hopefully the
final buglet has now been vanquished in the multi-byte
translation support. This one was a real nasty bugger.
Although it didn't occur with every terminal emulator,
occasionally random text lines were being chopped off.
As it turns out, those terminals were blameless. There
were two separate places in top's show_special routine
where potential multi-byte sequences were inadequately
addressed. Solution: exploit existing utf-8 functions.
[ it also became apparent that the translation hints ]
[ in the top_nls module were deficient. so a special ]
[ caution was added regarding the final line of txt. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Unlike the insp_mkrow_raw function the insp_mkrow_utf8
routine is not equipped to print non-ctl, non-printing
characters like '<7f>'. However, technically that very
value currently slips through the cracks. So with this
patch top will now print a space in the unlikely event
a character with the value of 127 is ever encountered.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since all the necessary utf-8 plumbing is now in place
this commit will extend multi-byte support to user and
group names. Now top will be on a par with the ps guy.
[ plus, it's also my way of showing appreciation for ]
[ all those investments silently made by translators ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Translatable column headers are supposed to be limited
to no more than 7 characters, even though some columns
are wider than that or even variable width. That value
of 7 is dictated by the Fields Management screen which
will otherwise truncate a column header longer than 7.
Our new utf-8 support did not adequately deal with the
potential need for truncation of column headers should
that limit of 7 be exceeded. This patch corrects that.
[ a few comments were also tweaked just a little bit ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit implemented multi-byte support for
the basic top user interaction and display provisions.
This commit completes multi-byte support by addressing
that 'Inspect Other Output' feature (the 'Y' command).
Few people probably exploit this very powerful feature
which allows the perusing of any file or piped output.
And even if nobody uses 'Y', someone will stumble over
it on the help screen and try it out. Assuming top was
not built with INSP_OFFDEMO defined, they'll end up on
the screen our translators have faithfully translated.
Without this patch, such a screen would display with a
bunch of 'unprintable' characters which will then show
in the standard (less-like) way as: '^A', '<C3>', etc.
In other words, those poor screens will be a big mess!
[ this program can even display an executable binary ]
[ while at that same time supporting Find/Find Next. ]
[ imagine, a file with no guarantee of real strings! ]
[ just try a Find using less with such binary files. ]
With this commit, the translated 'Y' demo screens will
now be properly shown, providing no invalid multi-byte
characters have been detected. Should that be the case
then they'll be displayed in that less-like way above.
And, if users go on to fully exploit this 'Y' command,
there is a good chance that a file or pipe might yield
output in a utf-8 multi-byte form. Should that be true
such output will thus be handled appropriately by top.
[ in many respects, this change was more challenging ]
[ than the basic support within the previous commit. ]
[ story of my life: least used = most effort needed. ]
Many thanks to our procps-ng translators which enabled
a proper test of these changed 'Y' command provisions:
. Vietnamese: Trần Ngọc Quân
. Polish: Jakub Bogusz
. German: Mario Blättermann
. French: Frédéric Marchal, Stéphane Aulery
[ and my sincerest apologies too, for my negligence! ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
When this project first began implementing translation
support nearly 6 years ago, we overcame many 'gettext'
obstacles and limitations. And, of course, there were
not any actual translations at the time so our testing
was quite limited plus, in many cases, only simulated.
None of that, however, can justify or excuse the total
lack of attention to top's approach to NLS, especially
since some actual translations have existed for years.
When the issue referenced below was raised, I suffered
immediate feelings of anxiety, doubt and pending doom.
This was mostly because top strives to avoid line wrap
at all costs and that did not bode well for multi-byte
translated strings, using several bytes per character.
I was also concerned over possible performance impact,
assuming it was even possible to properly handle utf8.
But, after wrestling with the problem for several days
those initial feelings have now been replaced by guilt
over any trouble I initially caused those translators.
One can only imagine how frustrating it must have been
after the translation effort to then see top display a
misaligned column header and fields management page or
truncated screens like those of help or color mapping.
------------------------------------------------------
Ok, with that off my chest let's review these changes,
now that top properly handles UTF8 multi-byte strings.
. Performance - virtually all of this newly added cost
for multi-byte support is incurred during interactions
with the user. So, performance is not really an issue.
The one occasion when performance is impacted is found
during 'summary_show()' processing, due to an addition
of one new call to 'utf8_delta()' in 'show_special()'.
. Extra Wide Characters - I have not yet and may never
figure out a way to support languages like zh_CN where
the characters can be wider than most other languages.
. Translated User Name - at some future point we could
implement translation of user names. But as the author
of the issue acknowledged such names are non-standard.
Thus task display still incurs no new multi-byte costs
beyond those already incurred in that escape.c module.
For raising the issue I extend my sincerest thanks to:
Göran Uddeborg
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'N_fmt' and 'N_txt' macros are interchangeable and
just highlight the 2 str types found in Norm_nlstable.
The change in this patch (strictly cosmetic) was found
during the coding for what will be the next 2 commits.
It has not been squashed into either of those so as to
not muddy up the waters for what was a major refactor.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Until this patch, top falsely assumed that there would
always be some (small) amount of physical memory after
subtracting 'used' and 'available' from the total. But
as the issue referenced below attests, a sum of 'used'
and 'available' might exceed that total memory amount.
I'm not sure if this is a problem with our calculation
of the 'used' amount, a flaw in the kernel 'available'
algorithms or some other reason I cannot even imagine.
Anyway, this patch protects against such a contingency
through the following single line addition of new code
. if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
The check for less than zero is not actually necessary
as long as the source numbers remain unsigned. However
should they ever become signed, we'll have protection.
[ Most of the changes in this commit simply separate ]
[ a variable's definition from its associated logic. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/64
Signed-off-by: Jim Warner <james.warner@comcast.net>
For the past 3 years top has fully honored that locale
LC_NUMERIC setting which impacts his refresh interval.
For the past nearly 5 years top has saved that refresh
value in a locale independent form in his config file.
With this commit we'll intentionally break top so that
a comma or period will be accepted for the radix point
regardless of what that LC_NUMERIC may have suggested.
The current locale LC_NUMERIC will, however, determine
how the delay interval is displayed in the 'd' prompt.
[ This position is better than the approach employed ]
[ by those coreutils 'sleep' and 'timeout' programs. ]
[ Both claim to permit floating point arguments. But ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/50
Prototyped by: Jan Rybar <jrybar@redhat.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ok, I admit it. I'm now tired of cleaning up after me.
This is the 3rd related tweak after that '-1' argument
was originally introduced. And with this patch we will
once again properly honor the '-o' and '-u|U' switches
without a need to be followed by an additional switch.
[ one can follow my unfortunate trail of alterations ]
[ beginning with my most recent fix referenced below ]
Reference(s):
commit 4b44aebd80
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the effective user id would always be present in
each proc_t, thus supporting 'u' filtering, other user
ids would only be present if /proc/$$/status was read.
This commit just puts the 'master' branch top on a par
with the 'newlib' branch when user filtering with 'U'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the introduction of a new '1' command line toggle
I have gone and broken a provision of the '-p' command
line switch (pids monitoring). Multiple pids could not
be specified through the use of comma delimited lists.
Thus, this commit simply corrects that newly added bug
which was born in the 'adjustment' commit shown below.
Reference(s):
. adjustment to '-1' implementation
commit 909b37d755
Signed-off-by: Jim Warner <james.warner@comcast.net>
There exists the possibility that a 'putp' call can be
issued before the 'setupterm' invocation has occurred,
as is reflected in a bugzilla report referenced below.
Strangely, such a SEGV isn't always triggered as logic
would suggest it ought to be. I experienced a fault in
these environments with the associated curses version:
. archlinux, procps-ng 3.3.12, ncurses 6.0.20170429
. fedora-25, procps-ng 3.3.10, ncurses 6.0.20160709
. opensuse-42.2, procps-ng 3.3.9, ncurses 5.9.20140201
. gentoo, procps-ng 3.3.12, ncurses 6.0.20150808
. slackw-14.2, procps-ng 3.3.12, ncurses 6.0.20160910
Whereas under these environments there was no problem:
. ubuntu-17.04, procps-ng 3.3.12, ncurses 6.0.20160625
. debian-test, procps-ng 3.3.12, ncurses 6.0.20161126
. mageia-5.1, procps-ng 3.3.9, ncurses 5.9.20140323
[ as an aside, the expected result in the bug report ]
[ is incorrect and should mention the '1' parameter. ]
[ however, until release 3.3.13 when the '1' becomes ]
[ a valid switch, numbers are not detected when used ]
[ with any switch which doesn't require an argument. ]
[ you're welcome to treat that as a separate bugglet ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1450429
Signed-off-by: Jim Warner <james.warner@comcast.net>
The top program already incorporated a modest delay at
startup so that some minimal process cpu history could
be established. However, Summary Area system level cpu
statistic history reflected usage since boot. As such,
unchanging % values would be shown with every restart.
This commit just adopts the same approach used in task
%CPU history for the Summary Area statistics. In other
words, it introduces a 'priming read' at startup as is
found in the newlib implementation for the <stat> API.
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/42
Signed-off-by: Jim Warner <james.warner@comcast.net>
This program has always tried to maintain an extermely
robust command line parsing procedure, far more robust
that what's available with the getopt stuff. But, with
the introduction of our first numeric switch it should
have been made even more robust than, in fact, it was.
This commit will now accomplish such a desirable goal.
Reference(s):
. added '1' command line switch
commit 89db82d143
Signed-off-by: Jim Warner <james.warner@comcast.net>
All of top's display was designed to fit into an 80x24
terminal. This includes the help screens plus both the
Summary and Task Areas, assuming no saved config file.
With release 3.3.10, the startup defaults were changed
assuming ./configure --disable-modern-top wasn't used.
This was done in the hope of introducing some users to
unknown capabilities such as colors, forest view, etc.
The purpose of this commit is to coax a few more users
into possibly exploring another capability: scrolling.
We do so by tweaking the default startup display so as
to show full command lines. Now, when things no longer
fit in 80x24, horizontal scrolling might be exploited.
[ of course, this can be reversed with the -c switch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
If built without ./configure --disable-modern-top, the
program displays each cpu individually providing there
is sufficient vertical screen real estate. For massive
SMP environments this will necessitate use of a config
file where the cpu summary toggle ('1') could be saved
via the 'W' command. But, an rcfile may not be viable.
So this commit introduces a '1' command line switch to
emulate exactly the effects of the interactive toggle.
And since it is our first numeric switch some existing
parsing logic had to be changed slightly. Such changes
are, in truth, an improvement. For example, instead of
seeing "inappropriate '2'" with ./top -2 we'll now see
the vastly more appropriate error "unknown option '2'.
References(s):
https://gitlab.com/procps-ng/procps/issues/55
Signed-off-by: Jim Warner <james.warner@comcast.net>
In their 3.2.7 version of top, Redhat introduced an -M
switch to automatically scale Summary Area memory data
to avoid truncation (and the resulting '+' indicator).
The procps-ng top does not employ suffixes with memory
data nor does it allow for different scaling with each
separate value. Rather, scaling appears at line start.
If built without ./configure --disable-modern-top, the
Summary Area memory will be scaled at GiB which should
lessen chance of truncation. Otherwise KiB was used to
reflect such memory, increasing the truncation chance.
And while 'W' can be used to preserve some appropriate
scaling value, there are arguments against such rcfile
approaches as cited in the issue and bug report below.
So this commit will bump the Summary Area memory scale
factor from KiB to MiB when using --disable-modern-top
as a concession to that Redhat bug report noted below.
And it also introduces a new command line switch which
can force any desired scaling regardless of the rcfile
or which ./configure option might have been specified.
[ for top's help text we'll show 'E' as if it were a ]
[ switch without arguments in order to keep the help ]
[ text displayable without wrap in an 80x24 terminal ]
[ the man page, however, will show all k-e arguments ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/53https://bugzilla.redhat.com/show_bug.cgi?id=1034466
Signed-off-by: Jim Warner <james.warner@comcast.net>
After much reflection I've come to the conclusion that
displaying 3 decimal places (usually) when memory data
had been scaled is no longer optimal with today's ever
increasing amounts. And given that not all task memory
fields are the same widths, inconsistencies can easily
arise as illustrated and discussed in the issue below.
Instead of unilaterally reducing the number of decimal
places, this commit will sneak in such a change via an
existing configure option that was very likely unused.
The former 'disable-wide-memory' option has now become
'enable-wide-memory', which can be used if the current
behavior (3 decimal places) is preferred. Without that
option, whenever memory is scaled beyond KiB, just one
decimal place will be shown in Summary and Task areas.
And Task area field width will no longer be changed by
this revised configure option. Instead, all such field
widths will now be fixed at the former maximum values.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/50
Signed-off-by: Jim Warner <james.warner@comcast.net>
By default the file HOME/.toprc will be prefered. This ensures there
should be minimal breakage even if this file is later created by some
other means. Otherwise we will follow the new behaviour described by
the XDG Base Directory Specification:
If the XDG_CONFIG_HOME environment variable is available we will attempt
to use this as XDG_CONFIG_HOME/procps/toprc otherwise we will fall-back
to HOME/.config/procps/toprc instead.
Signed-off-by: Earnestly <zibeon@gmail.com>
That issue cited below prompted some changes under the
newlib branch to standardize the calculation involving
busy, idle, user & system accumulated plus delta tics.
This patch will bring our master branch version of top
into agreement with that newlib version which exploits
some of those newly added library extended provisions.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/48
Signed-off-by: Jim Warner <james.warner@comcast.net>
It makes no sense to begin our tracked nested level at
'1' then later require a '1' to be subtracted from the
level as artwork and indentation is added for display.
By beginning such tracked levels at zero, we can avoid
the need to adjust it & use it directly in a snprintf.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just parallels some adjustments/corrections
which were also implemented under the 'newlib' branch.
[ remaining differences between man documents relate ]
[ to old kernels with topic '2b. TASK and CPU State' ]
[ and a note in '4c. SORTING' for TTY + WCHAN fields ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Still unhappy with a minor memory leak associated with
libnuma, I experimented with omitting the dlclose that
was issued at module's end. For some reason which will
remain a mystery, the valgrind leak then went bye-bye.
So this patch just omits one use of dlclose and relies
on whatever kernel magic is at work to free the memory
when each process ends. We kept, however, the original
code (now commented-out) to serve as a future caution.
There remains one potential (but unlikely) dlclose use
near the original dlopen. But there will be no leak as
that 'numa_node_of_cpu' will not yet have been called.
This seems to be the culprit that triggers such leaks.
None of this libnuma shit would likely have come close
to hitting our fan had the numa developers provided us
with 'new' and 'unref' functions like our newlib does.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
After discovering those terrible costs associated with
/proc/status vs. /proc/stat, the build_header function
changed to favor the latter for a field found in both.
Well, low-and-behold, this top program still used some
flags that needlessly caused 'status' to still be read
when 'statm' could have served. And, while top's needs
require conversion from pages to KiB, that's still far
less costly than reading that gosh darn 'status' file.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Long ago, in a galaxy far away, top was convinced that
/proc/stat was to be favored over /proc/status if some
field could be satisfied with either. This was done to
avoid extra costs of 64-bit math for 32-bit platforms.
Well, its time to acknowledge the prevalence of 64-bit
platforms. And in such an environment there is a large
hidden cost currently if using status instead of stat.
In fact, that cost difference can be as high as 1400%.
So, this commit will coax top into favoring that least
costly route while also fixing an EU_TGD library flag.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides for raising the total displayable
fields from its current 70 to 86. It also bumps the id
in an rcfile representing the version from 'i' to 'j'.
The increase in number of fields will make sharing the
rcfile with an older top, once it's saved, impossible.
These changes are being done via a #define rather than
hard coded so any such sharing will still be possible.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whoa, I had never considered an alternative to ncurses
until the issue referenced below was raised. Thus, I'm
surprised to find that 'tparm' was the only impediment
to ultimately utilizing this alternate curses library.
And, while we could have substituted that non-standard
'tiparm' with only 2 arguments, we'll utilize the full
parms compliment in the spirit of that original patch.
Frankly, the task of developing an alternative library
to that ncurses implementation really boggles my mind.
Congratulations to rofl0r, whoever that masked man is.
Reference(s):
. issue raised
https://gitlab.com/procps-ng/procps/issues/38
. netbsd-curses home
https://github.com/sabotage-linux/netbsd-curses
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adapts the ps program to a newly add proc_t
field and provides for new support in that top program
along with his man document (ps was already ok there).
Signed-off-by: Jim Warner <james.warner@comcast.net>
We'll follow Craig's lead and whack some author stuff.
[ and we'll honor the SEE ALSO guideline for periods ]
[ but essentially ignore all the other busybody crap ]
[ which, to be honest, we pretty much follow already ]
[ actually, if you're told to follow a certain style ]
[ in program examples, you've gone way past busybody ]
[ crap and have entered the realm of anal retentive! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This development (only) define can be used to turn top
into a simple text program, disabling termcap effects.
But input (at screen bottom) suffers from a line wrap.
So, this commit just makes the input prompt processing
a little more effective by adding one leading newline.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and all users exposed to those 'out of memory' fields,
it's about time we added them to the top man document.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Using the <STAT> api under the newlib branch, that top
program is very responsive to changes in the number of
on-line cpus. However under the master branch this top
program is very responsive only to losses of some cpu.
When a cpu is brought back on-line potential delays of
60 seconds could be encountered. That delay was simply
an attempt to reduce costs and reflected the erroneous
assumption that adding a cpu required physical effort.
So without redesigning the cpu refresh code to emulate
that of newlib, this commit just reduces the potential
delay to 3 seconds (the same that is used for memory).
[ As an aside, if one wants to have their confidence ]
[ in that htop program badly shaken, try taking some ]
[ cpus off-line & on-line again while it is running. ]
[ Poor ol' htop just continues to report results for ]
[ whatever were the cpus when started. Nice feature, ]
[ but I wonder where those phantom results are from. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just tries to parallel that newlib branch.
It contains the following changes, which were prompted
by the newlib coverity analysis which Craig initiated:
. comment typo predicting 'String not null terminated'
. eliminate 'Logically dead code' from insp_make_row()
Some tweaks, unrelated to coverity, are also included:
. use more modern (recommended) approach for time call
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just tries to parallel the implementations
in the newlib branch. The config file Rc.zero_suppress
will be extended to include both out-of-memory fields.
And while we're at it, we'll also extend zero suppress
to that NI (nice value) field, which already should've
had it. Plus we trade those namespaces custom suppress
logic for our now slightly enhanced make_num function.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since support already exists in the newlib branch this
represents an equivalent master branch implementation,
and this commit message is shared with 2 more patches.
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
p.s. Locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
p.p.s. Archlinux, Debian-stretch and Fedora-23 already
are currently using a 4.5 linux kernel (as of 6/2/16).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since support already exists in the newlib branch this
represents an equivalent master branch implementation,
and this commit message is shared with 2 more patches.
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
p.s. Locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
p.p.s. Archlinux, Debian-stretch and Fedora-23 already
are currently using a 4.5 linux kernel (as of 6/2/16).
Signed-off-by: Jim Warner <james.warner@comcast.net>
After experimenting with those 4.5 kernel enhancements
to /proc/<pid>/status, that newly added overview topic
'Memory Types' was found to be in need of some tweaks.
In addition, the 'DATA' description wasn't quite broad
enough since explicit private file mappings impact it.
( lastly, for the record, the 2nd commit referred to )
( below contained an incorrect reference that should )
( have been the original issue 21 commit. instead it )
( showed an invalid SHA-1 hash. i believe i have now )
( identified a flaw in my workflow that produced it. )
Reference(s):
. original patch responding to issue #21
commit e4bbd3ca1a
. subsequent patch with invalid commit ref
commit 5dcbcd00fe
Signed-off-by: Jim Warner <james.warner@comcast.net>
