Commit Graph

2739 Commits

Author SHA1 Message Date
Jim Warner
541567a189 doc: tweak top man page for changes to field additions
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:01:32 +11:00
Jim Warner
46aa96e438 top: provide an unlimited capacity for field additions
With each of those references shown below, the maximum
number of fields was increased. However, with a 'char'
based implementation we're nearing the upper limits of
total displayable fields. We currently use 76 of a max
of 86 fields. With extra effort, 94 might be possible.

But 94 is the absolute upper limit of possible fields!

Moreover, the current implementation yields characters
that were unprintable in the rcfile. This could become
an issue with that 'inspect' feature when/if an rcfile
is edited to add entries (as opposed to using 'echo').

So, with this commit the internals of field management
has been completely reimagined. It is now based on the
integer type, not a character. And whereas that former
design used the high order bit to show the 'on' state,
thus yielding an unprintable character, the new design
uses the low order bit for the state. As such, numbers
will be kept small and an even number will be an 'off'
field whereas an odd number will become an 'on' state.

The bottom line is that this new design will afford an
unlimited number of new fields while keeping an rcfile
completely free of that potential unprintable garbage.

And it is embarrassingly easy to extend the maximum of
supportable fields from the currently implemented 100.
Who knows, maybe a future patch will prove this point.

[ unless a subsequent commit proves otherwise, given ]
[ the dramatic differences in rcfile contents, i had ]
[ to abandon the practice of supporting old rcfiles. ]

Reference(s):
. Nov, 2013 - RCF_PLUS_H introduced
commit af4e6533ba
. Jul, 2016 - RCF_PLUS_J introduced
commit d5c5051fb3

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:01:32 +11:00
Jim Warner
c493fca892 top: warn of man page impact if 'USE_X_COLHDR' defined
This warning was added after discovering openSUSE uses
the option with (at least) their 'tumbleweed' version.

The man document sections impacted are: 4e, 5d and 5e.
That is where it was asserted sort column highlighting
would be temporarily turned off if search ('L') and/or
filtering ('O') is active. This option makes it false.

[ shame on suse for not also correcting the man page ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:01:32 +11:00
Jim Warner
53917334d0 ps: plus for symmetry 'UTILIZATION_C' is newest format
This commit just compliments a change referenced below
by providing the value which includes reaped children.

[ as an aside, it looks like ps only includes reaped ]
[ children values under an obscure BSD or GNU option ]

[ so, this change is possibly of even more relevance ]

Reference(s):
. Mar, 2022 - added %CUU
commit 2ac72e2e80

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-07 20:29:06 +11:00
Jim Warner
cfa5538832 top: and for symmetry 'UTILIZATION_C' is newest column
This commit just compliments a change referenced below
by providing the value which includes reaped children.

Reference(s):
. Feb, 2022 - added %CUU field
commit 7647e96b0a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-07 20:29:06 +11:00
Jim Warner
813661c299 library: introduced a 'UTILIZATION_C' item, <pids> api
Some items in the <pids> API carry a '_C' suffix which
implies such values include reaped children. So, we'll
now extend this practice to that new UTILIZATION item.

Reference(s):
. Mar, 2022 - tweak PIDS_UTILIZATION
commit 9c0e8e9429
. Feb, 2022 - added PIDS_UTILIZATION
commit c69104b2b8

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-07 20:29:06 +11:00
Jim Warner
6490349e64 ps: enabled sort with 'utilization' related specifiers
When %CUU was added, in the commit referenced below, I
stated that 4 similar specifiers already existed. Well
I misspoke since there is actually 5 including 'util'.

Each of those fields had no sort capability. Since the
values are dynamically calculated, they were forced to
use 'PIDS_extra' as the format_array 'sr' designation.

Now each will use 'PIDS_UTILIZATION' and be sort-able.

[ yes, sometimes the calculated values could contain ]
[ reaped children while the sort field does not. but ]
[ such disparity depends on obscure bsd/gnu options. ]

Reference(s):
. Mar, 2022 - added %CUU
commit 2ac72e2e80

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-07 20:29:06 +11:00
Jim Warner
e4e7991a26 top: enhanced 'scale_tics' function for Ctrl-E scaling
When scale_tics was refactored and then Ctrl-E support
added to top, the complete range of scaling values was
not visible. Namely, a single 'd' (days) & 'w' (weeks)
was never seen with ^E. With this commit they will be.

Reference(s):
. Mar, 2022 - introduced ^E tics scaling
commit 402bf1903b
. Mar, 2022 - refactored scale_tics
commit 71eb90c1b2

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-07 20:29:06 +11:00
Jim Warner
81df85a1b5 ps: swat insidious bug with the %cpu' format specifier
Whoa, my head really hurts but this commit should help
with a speedy recovery hopefully, after it is applied.

If the '%cpu' field is used as a format specifier with
that 'o' option, you will encounter a SIGSEGV if there
is also an invalid argument on that same command line.

For example, try 'ps/pscommand -o %cpu,x' with newlib.
With any format specifier other than the '%cpu', there
is an error message, as would happen with '-o pcpu,x'.

For a 3.3.17 version of ps, there's no abend. Instead,
the program will just display a bunch of gobbledygook.
This boo-boo was found to exist as far back as v3.3.0.

[ ok, i am starting to feel very much better already ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
2ac72e2e80 ps: exploit the library addition for 'cpu utilization'
This just parallels the top program by adding that new
library PIDS_UTILIZATION item to the ps repertoire. It
should be noted, however, that the new %CUU field is a
little redundant. I mean, ps already has 4 such fields
implemented identified as: '%cpu', 'c', 'cp' & 'pcpu'.

Oh well, at least the newest one offers a little value
added in the form of extra precision. We'll follow the
top lead and display results in the form of: '##.###'.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
9c0e8e9429 library: guard against 'inf/nan' for 'cpu utilization'
When preparing the ps program for a %CUU field, it was
revealed the PIDS_UTILIZATION item may sometimes yield
a result of 'nan' or 'inf' for that ps program itself.

Apparently, it was caused by the short lived nature of
such a one-shot program. And, while this anomaly could
be handled in ps, the solution belongs in the library.

So, I reworked an item's algorithm to avoid this oops.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
5c4c239257 doc: document 'scale_tics' function for Ctrl-E scaling
[ i also tweaked that 'STARTED' narrative just a bit ]
[ since its original wording implied the value could ]
[ change, whereas it's fixed when a task is started. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
402bf1903b top: extended 'scale_tics' function for Ctrl-E scaling
That normalization of the 'scale_tics' function in the
prior commit convinced me that I won't please everyone
with my arbitrary choices for the scaling transitions.

So, this patch will provide the users with a means for
setting their own scaling transition points with a new
toggle. Ctrl-E was chosen since the 'e/E' toggles were
already present as a means of scaling (albeit memory).

[ this toggle will also serve an educational purpose ]
[ by allowing one to see all the scaling conventions ]

The scaling a user establishes is saved in the rcfile.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
71eb90c1b2 top: refactor 'scale_tics' function for better scaling
This patch refactors the 'scale_tics' function to more
closely parallel uptime shown on the first line of the
summary area. The old logic has been preserved through
the header file's new  #define SCALE_FORMER provision.

However, the former logic was actually a big disaster.
These are some potential problems with that old logic:

1. With respect to our time fields top no longer deals
solely with cpu time. So, the old limits of '68 weeks'
could possibly be insufficient to reflect those times.

2. Given the widths of top's new time fields, the code
never got beyond scaling to hours. For example, with a
ridiculously large span of 19 years, the scaled result
would then be shown as '167832h'. We never reached the
days ('6993d') or even the weeks ('999w') equivalents.

3. Similarly, with that 'TIME+' field and a large tics
value, results would then appear as 'MMMMMM:SS' rather
than the more meaningful 'HH:MM:SS' or days and hours.

So henceforth we will adopt these scaling conventions:

  MMM:SS.hh ... minutes:seconds.hundredths
  MMM:SS ...... minutes:seconds
  HH,MM ....... hours,minutes
  D+H ......... days+hours (with 'd' & 'h' suffixes)
  D ........... days (with 'd' suffix)
  W+D ......... weeks+days (with 'w' & 'd' suffixes)
  W ........... weeks (with 'w' suffix)

Note that, unlike our former scaling logic, that 'MMM'
portion won't be allowed to grow unconditionally. It's
limited (arbitrarily?) to 360 total minutes (6 hours).
Additionally, the 'HH' guy will be limited to 96 hours
(4 days) while that 'D' limit was set at 14 (2 weeks).

Whenever a limit is hit, scaling will advance a level.

Reference(s):
. Feb, 2022 - added 'ELAPSED'
commit 9348d3b008
. Feb, 2022 - added 'STARTED'
commit 7647e96b0a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 14:52:34 +11:00
Jim Warner
9348d3b008 top: added some elapsed running time 'ELAPSED' support
When the 'STARTED' field was added, in the message for
the commit referenced below, I explained why 'ELAPSED'
shouldn't be implemented though it might be preferred.

Well, after climbing out of my box to do a little more
thinking, I came up with the way to add that 'ELAPSED'
field while avoiding the possible performance penalty.

Just do not show what would change with every refresh!

If we do not show the seconds portion of a scaled tics
amount then the problem goes away. And this comes with
an additional benefit. The HH,MM (hours,minutes) style
then is readily compared with that system uptime shown
as HH:MM. The only difference is just the comma/colon.

[ assuming the top uptime/load average toggle was on ]

Reference(s):
. introduced 'start time' field
commit 7647e96b0a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-28 20:21:00 +11:00
Jim Warner
a749414f16 top: tweaked the recently introduced 'STARTED' support
When the 'STARTED' field was added, the width was made
the same as the 'TIME+' field. Thus, a full time could
be shown (which then included hundredths of a second).

That kind of granularity is totally unnecessary. After
all, this column is potentially confusing enough since
it is so counterintuitive. So, this commit will reduce
the width of the field with some help from scale_tics.

Henceforth it will not include those ol' centiseconds.

[ along the way let's expand the man document with a ]
[ a remainder about content representation & scaling ]

Reference(s):
. introduced 'start time' field
commit 7647e96b0a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-28 20:21:00 +11:00
Jim Warner
c89421e83a library: trade 'float' type for a 'double', <pids> api
While we really do not need the extra precision, we'll
trade that recently introduced float type for a double
for efficiency on a 64 bit platform. Additionally, the
UTILIZATION algorithm was tweaked producing less code.

The net result is four fewer machine instructions with
a reduction of 14 total bytes in that function's size.

Reference(s):
. introduced 'real' type & 'utilization' item
commit c69104b2b8

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-28 20:21:00 +11:00
Jim Warner
831bd8cf29 w: responded to those library changes for 'TIME' stuff
The library refactored 'TIME' items for consistency so
we must adapt to some new data types and calculations.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
8f5a755d11 ps: response to those library changes for 'TIME' stuff
The library refactored 'TIME' items for consistency so
we must adapt to some new data types and calculations.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
9b80d47df5 pgrep: adapted to the library changes for 'TIME' stuff
The library refactored 'TIME' items for consistency so
we must adapt to some new data types and calculations.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
a39f2bffdc doc: updated with new 'start time' & 'cpu utilization'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
7647e96b0a top: added fields for 'start time' & 'cpu utilization'
This patch will exploit some new library capabilities.

[ one will raise eyebrows, the other likely will not ]

A new 'STARTED' field was added which shows the time a
process started after system boot. As such the largest
interval represents the most recently started process.

This is the field that will likely be questioned since
it's somewhat counterintuitive. But were we to instead
use TIME_ELAPSED, the value will change with every top
refresh. This will defeat any PUFF macro optimization.

The new '%CUU' field will probably be better received.
It represents the cpu usage over the life of the task.
When a process was showing high %CPU usage, this field
can be used to determine if it's an anomaly or normal.

[ and as with %CPU, %CUU shows a '?' when running in ]
[ a namespace when /proc was mounted with subset=pid ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
c69104b2b8 library: added important new functionality, <pids> api
This commit introduces some new capabilities available
in libproc-2 under the <PIDS> interface. Along the way
errors impacting some item values have been corrected.

The following summarizes the major changes being made.

1. The PIDS_TIME_START item was represented as seconds
since system boot but really held tics since boot. And
some programs properly divided it by Hertz to actually
yield seconds while others acted as if it already was.

So, now we have a new PIDS_TICS_BEGAN field and all of
the 'TIME' fields properly reflect seconds. With those
'TIME' fields, the type was changed to 'float/real' so
one could convert it back to tics without loss of some
centiseconds reflected in the Hertz guy (usually 100).

2. The boot_seconds was established in procps_pids_new
meaning it was fixed/unchanging. As a result, one item
(PIDS_TIME_ELAPSED) was rendered useless. So now, each
of the three retrieval functions establishes a current
boot_seconds well before the set functions are called.

3. Added a PIDS_UTILIZATION item that will provide the
CPU usage over the life of a process, as a percentage.

4. Added PIDS_TIME_ALL_C for symmetry with the similar
item called PIDS_TICS_ALL_C (which reflects raw tics).

5. That 'derived from' notation has been added to some
additional header items to reflect their true origins.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
854e85a50b doc: minor tweaks affecting three newlib man documents
. add the proper function names to the procps_pids man
page when discussing the 'LIBPROC_HIDE_KERNEL' feature
under recently added 'ENVIRONMENT VARIABLE(S)' section

. ensure the 'SEE ALSO' references are comma delimited

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
95990dceb1 top: just trade an assignement for a manifest constant
The assignment was originally created to reduce length
of one line of code (i.e. for readability). But we can
achieve this objective without adding executable code.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
98ca9fe367 top: trade that 'strncpy' for more efficient 'memccpy'
This patch was prompted by the merge request for pgrep
referenced below. In top's case, any performance gains
will be minimal since the now defunct strncpy was only
employed for termcap rebuilds after interacting with a
user (+ 1 other non-termcap related user interaction).

[ golly, strncpy always calls at least two functions ]
[ but usually calls a total of 3. on the other hand, ]
[ memccpy will only call a maximum of two functions. ]

And thanks to Baruch Siach for these strncpy insights.

Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/148

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:23:30 +11:00
Jim Warner
787615d8da top: tweak a couple task_show() macros for consistency
There was a potential problem with these macros should
that '#define SCROLLVAR_NO' be active and they were to
appear in an 'if' statement (like is necessary for the
master branch version of top under that EU_CMD label).

[ now they're always usable without requiring an ';' ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:23:30 +11:00
Jim Warner
2c12f1f295 top: let's eliminate some additional compiler warnings
This patch eliminates those warnings referenced below.
They are sometimes associated with an obscure #define.

We'll also corrrect one header file function prototype
so it will aggree with the actual function definition.

Reference(s):
top.c: In function 'adj_geometry':
top.c:1874:20: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
 1874 |    if (Screen_cols < DOUBLE_limit) Curwin->rc.double_up = 0;
      |                    ^
top.c: In function 'zap_fieldstab':
top.c:2359:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 2359 |    if (wtab[EU_CPN].wmin < digits) {
      |                          ^
top.c:2365:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 2365 |    if (wtab[EU_NMA].wmin < digits) {
      |                          ^
top.c: In function 'keys_summary':
top.c:5128:45: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
 5128 |          if (w->rc.double_up && Screen_cols < DOUBLE_limit) {
      |                                             ^
top.c: In function 'sum_tics':
top.c:5605:22: warning: unused variable 'num_syst' [-Wunused-variable]
 5605 |    int ix, num_user, num_syst;
      |                      ^~~~~~~~
top.c:5605:12: warning: unused variable 'num_user' [-Wunused-variable]
 5605 |    int ix, num_user, num_syst;
      |            ^~~~~~~~

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:23:30 +11:00
Jim Warner
0847ea8360 top: attempt to clarify the 'iokey' parameter meanings
The 'iokey' function's parameter 'action' was utilized
with literal numbers in the calling functions. So this
change will replace those literal numbers with #define
constants which, one hopes, will clarify their impact.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:23:30 +11:00
Craig Small
e5542f1fc3 free: Use wstr width and not length
The previous commit used the value from mbstowcs() to work out
the spacing required, as printf() got it completely wrong.

However, for alignment of text you don't use the string length
but the string width.

As the referenced website says:
 Use wcslen when allocating memory for wide characters, and use wcswidth to
 align text.

Which is what free does now. Chinese is still off by one but I cannot
see why this is so. It's close enough for now. If someone can work
it out, I'd love to know what the fix is.

As a side effect, #213 is fixed because we are putting the correct
number of spaces in.

French is still an issue (see #24 ) but this is because the string is
too long!

References:
 procps-ng/procps#24
 procps-ng/procps#213
 procps-ng/procps#229
 commit 9f4db0fb56
 https://www.linux.com/news/programming-wide-characters/

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-02-01 16:46:09 +11:00
Craig Small
9f4db0fb56 free: Fix first column justification
free has for many years had a problem with translated header columns
or the first column. This is because printf("-9s", str) doesn't use
the wide length of the string but the char length meaning they are
mis-aligned.

Using the mbstowcs() function to get the wide length and then
a precision parameter to append the right number of spaces after the
number means we get what we need.

References:
 procps-ng/procps#229
 procps-ng/procps#204
 procps-ng/procps#206
 https://bugs.debian.org/1001689

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-01-31 18:14:12 +11:00
Jim Warner
50a0d9a56c NEWS: updated to acknowledge 'LIBPROC_HIDE_KERNEL' var
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-31 18:10:48 +11:00
Jim Warner
9ad78da984 top: tweak the heck out of some command line help text
This patch began as just an attempt to make any option
which also included an argument a little more readable
by adding one space before the '=ARGUMENT' convention.

[ by the way, i don't agree with most of those other ]
[ procps-ng programs that use an '<arg>' convention. ]
[ it's too easily misread as an 'optional' argument. ]

[ top uses a convention like that found in coreutils ]
[ albeit now with one extra space before the equals. ]

In adjusting those arguments it was apparent that many
explanations already lined up nicely at the right hand
margin. So, this commit will force right-justification
with all explanations (as we do with commit messages).

[ and as a final challenge, for those options taking ]
[ an argument, that argument was repeated within the ]
[ explanation and made the rightmost item on a line. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-31 18:10:48 +11:00
Jim Warner
bc8b5a06b8 top: eliminate the potential warnings '-Wsign-compare'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-31 18:10:48 +11:00
Jim Warner
d1c6a69a61 top: avoid a potential warning '-Wmaybe-uninitialized'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-31 18:10:48 +11:00
Jim Warner
b9b0f408b8 top: avoid a possible warning '-Wimplicit-fallthrough'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-31 18:10:48 +11:00
Jim Warner
1387c7f84b top: add visual clue when focus toggle ('F') is active
When in forest view mode, that focus toggle ('F') is a
useful tool occasionally. But, if a focused parent has
enough cloned siblings to exceed screen rows, it could
be hard to remember that such a toggle remains active.

So, this patch will provide a subtle visual clue added
to the leftmost position in the COMMAND column. Now if
the focus toggle was active, regardless of total tasks
affected, the users will always know when it's active.

Reference(s):
. -7/24/21, introduced new focus toggle
commit 3e922e671d
. 09/23/21, ensure focused tasks stay focused
commit 69978e3650

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:26:17 +11:00
Jim Warner
99c1f0578f top: correct one source comment plus one man page oops
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:26:17 +11:00
Jim Warner
a6c564361b top: banish one more warning for '-Wformat-truncation'
In the commit referenced below, I fixed what I thought
was all the top 'truncation' warnings. For that commit
I had been using CFLAGS='-ggdb -Wall'. However, if one
uses just a vanilla './configure', then a hidden extra
warning will surface. This patch will finally kill it.

[ thanks a bunch gcc - we love this kind of behavior ]

Reference(s):
. 01/08/22, original warning fix
commit 44ca06f1a0

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:26:17 +11:00
Jim Warner
7418b97344 sysctl: eliminate a warning '-Wmisleading-indentation'
[ and in the affected function, we'll also eliminate ]
[ all those f**king tab characters making a hot mess ]
[ of any attempt at a properly formatted C function! ]

[ plus i adjusted a little non-tab misalignment too! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-13 19:34:39 +11:00
Jim Warner
14281269f8 top: eliminate warnings for '-Wmisleading-indentation'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-13 19:34:39 +11:00
Jim Warner
44ca06f1a0 top: eliminate every warning for '-Wformat-truncation'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-13 19:34:39 +11:00
Jim Warner
4fdba9627a library: Better PID file checks (with one small tweak)
Since gcc no longer warns of 'unreachable code', we'll
just deal with any such possibility ourselves I guess.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-13 19:34:39 +11:00
Craig Small
39d4d147d7 library: Better PID file checks
This started off with fixing the compilier warning:

proc/readproc.c: In function ‘simple_nextpid’:
proc/readproc.c:1373:38: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 58 [-Wformat-truncation=]
 1373 |   snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
      |                                      ^~
proc/readproc.c:1373:3: note: ‘snprintf’ output between 7 and 262 bytes into a destination of size 64
 1373 |   snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We know that ent->d_name will fit under 64 bytes because we check the
name starts with a digit. The first change was simple and changed the
printf to use tgid like the task function below it.

Is everything under /proc that starts with a digit a directory with a
PID only? Today, it is but there are no guarantees.

The entire function works ok if every non-pid directory doesn't start
with a number. We don't check for strtoul() having an issue nor
if the for loop just falls off the end. The moment the kernel guys
(or some module writer) think "/proc/12mykernelval" is a neat idea this
function is in trouble. We won't get buffer overflow as we are
using snprintf at least.

This change now:
 We check if strtoul() actually came across a number
 Process the pid directory as a conditional branch
 Treat falling off the for loop as a not-found

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-01-08 07:49:13 +11:00
Craig Small
8b67402a25 pmap: Fix minor compiler warning
/usr/include/x86_64-linux-gnu/bits/error.h:40:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   40 |     __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pmap.c: In function ‘main’:
pmap.c:760:35: note: format string is defined here
  760 |         xerrx(EXIT_FAILURE, "%s: '%s'", _("failed to parse argument"), optarg);

A simple check for optarg being null silenced this, not sure why only
this one was a problem.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-01-08 07:47:46 +11:00
Jim Warner
91ffe81734 misc: fixed several inconsistencies in email addresses
[ you wouldn't believe how many back-and-forths were ]
[ involved in Craig convincing me there were several ]
[ inconsistencies. i am so dense sometimes (often?). ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-08 07:15:59 +11:00
Craig Small
c83cd6e6c0 top: Fix my email address
Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-01-07 19:29:23 +11:00
Jim Warner
e243721f22 doc: updated 3 man pages for 'LIBPROC_HIDE_KERNEL' var
This patch was prompted by Björn Fischer's merge #147
request referenced below. And since the library change
may impact all users, multiple man pages were updated.

[ and thanks to Björn for initiating this extension ]

Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/147

Prototyped-by: Björn Fischer <bf@CeBiTec.Uni-Bielefeld.DE>
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-07 19:19:15 +11:00
Jim Warner
2a7ec67ac8 library: add support for the 'LIBPROC_HIDE_KERNEL' var
This patch was prompted by Björn Fischer's merge #147
request referenced below. It has been generalized such
that it now embraces both of those 'pids_fetch' types.

[ and thanks to Björn for initiating this extension ]

Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/147

Prototyped-by: Björn Fischer <bf@CeBiTec.Uni-Bielefeld.DE>
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-07 19:19:15 +11:00
Jim Warner
cbff1dd106 top: bust up that overly large 'summary_show' function
Over the years the summary_show function has increased
from around 77 lines of code & comments to its current
size of 243 lines. This is well beyond an ideal length
of available screen rows. So this patch will split it.

We'll take the cpu and memory duties and make separate
functions out of them. Of course, this will incur some
additional call overhead but, given current cpu/memory
logic, any such increase really becomes insignificant.

Now summary_show's a svelte 57 lines of code/comments.

[ this is like what was done to that do_key function ]
[ a decade ago except overhead of new function calls ]
[ plus table lookup was even less of a concern since ]
[ a human was involved, not normal iterative output. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-07 19:19:15 +11:00