@steffhip found that while the translation hint said use 9 characters in
the free headers, it really was only 7.
Currently each line is constructed with the following (in non wide format):
Header + 6 Columns. The header takes 7 characters and each column is 11
characters wide and prefixed with one space. Thus we have
7 + (1 + 11) * 6 = 79 characters for each line
By dropping the leading space for the first column after the header -the
header is already terminated by a colon- one could indeed provide the needed
9 letters for the header and thus have 9 + 11 * 1 + (1 + 11) * 5 = 80 Chars
per line which would fit into one line.
@steffhip found that while the translation hint said use 9 characters in
the free headers, it really was only 7.
Currently each line is constructed with the following (in non wide format):
Header + 6 Columns. The header takes 7 characters and each column is 11
characters wide and prefixed with one space. Thus we have
7 + (1 + 11) * 6 = 79 characters for each line
By dropping the leading space for the first column after the header -the
header is already terminated by a colon- one could indeed provide the needed
9 letters for the header and thus have 9 + 11 * 1 + (1 + 11) * 5 = 80 Chars
per line which would fit into one line.
Well, shit! With release 4.0 on March 25th the lxc/lxd
folks have stuck it to us once again. They changed the
cgroup lxc prefix used to identify the container name.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Well, shit! With release 4.0 on March 25th the lxc/lxd
folks have stuck it to us once again. They changed the
cgroup lxc prefix used to identify the container name.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reimplementation of pidof for procps toolset contains sort of deactivated code and does not return results for processes without task.cmdline entry (usually kernel worker threads). Old pidof and pgrep do that in comparison. Despite all perks provided by using pgrep instead, pidof should show those workers again.
Reimplementation of pidof for procps toolset contains sort of deactivated code and does not return results for processes without task.cmdline entry (usually kernel worker threads). Old pidof and pgrep do that in comparison. Despite all perks provided by using pgrep instead, pidof should show those workers again.
Several years after the 'e' & 'E' interactive commands
were introduce to affect memory scaling, an 'E' switch
was added. This was after discovering a dropped Redhat
patch which provided a unique 'M' command line switch.
If only for symmetry it makes sense to offer a similar
command switch ('e') for the Task Area memory scaling.
As was true with 'E', top's help text will show 'e' as
if it were a switch without arguments in order to keep
help text displayed without wrap in an 80x24 terminal.
The man page, however, will show all of the arguments.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/165
. 03/2017, added 'E' command line switch
commit b2bd65407a
. 12/2012, added 'e' interactive command
commit 21e550bc08
. 12/2012, added 'E' interactive command
commit bc46f67f9a
Signed-off-by: Jim Warner <james.warner@comcast.net>
Several years after the 'e' & 'E' interactive commands
were introduce to affect memory scaling, an 'E' switch
was added. This was after discovering a dropped Redhat
patch which provided a unique 'M' command line switch.
If only for symmetry it makes sense to offer a similar
command switch ('e') for the Task Area memory scaling.
As was true with 'E', top's help text will show 'e' as
if it were a switch without arguments in order to keep
help text displayed without wrap in an 80x24 terminal.
The man page, however, will show all of the arguments.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/165
. 03/2017, added 'E' command line switch
commit fb48b5d9fb
. 12/2012, added 'e' interactive command
commit 21e550bc08
. 12/2012, added 'E' interactive command
commit bc46f67f9a
Signed-off-by: Jim Warner <james.warner@comcast.net>
The Debian bug referenced below has nothing to do with
locales. In fact, top was made locale independent back
in release 3.3.13 (April, 2018). However, that bug did
reveal some misplaced logic which this patch corrects.
Prompted by the Qualys audit, all rcfile field strings
were checked for potential duplicates which could only
have resulted from some user's manual/malicious edits.
Unfortunately, that code was executed before top had a
chance to enforce the proper/maximum string length (in
the event an extremely old rcfile had just been read).
This created some potential string overrun references.
In top's original 3.3.15 implementation, the potential
overrun extended for 15 characters. That is the number
of field characters added with 3.3.9 (December, 2013).
But, since strchr() was used, no error exit was taken.
In the revised 3.3.16 implementation, the strchr() was
replaced with '&w->rc.fieldscur[n]'. This held overrun
to a single position while producing an error message.
So, this commit just moves that logic to a point where
fieldscur is guaranteed to be longer than EU_MAXPFLGS.
Reference(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951335
. revised 3.3.16 validation logic
commit 775223a817
. original 3.3.15 validation logic
commit 085351a0ee
Signed-off-by: Jim Warner <james.warner@comcast.net>
When that potential abend at program end was addressed
in the patch shown below, one line of code was removed
in error. That line served to suppress some end-of-job
reports should ATEOJ_RPTSTD or ATEOJ_RPTHSH be active.
So, this patch restores that previously deleted logic.
Reference(s):
. potential SEGV fix, newlib branch
commit 90c22e64ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
The Debian bug referenced below has nothing to do with
locales. In fact, top was made locale independent back
in release 3.3.13 (April, 2018). However, that bug did
reveal some misplaced logic which this patch corrects.
Prompted by the Qualys audit, all rcfile field strings
were checked for potential duplicates which could only
have resulted from some user's manual/malicious edits.
Unfortunately, that code was executed before top had a
chance to enforce the proper/maximum string length (in
the event an extremely old rcfile had just been read).
This created some potential string overrun references.
In top's original 3.3.15 implementation, the potential
overrun extended for 15 characters. That is the number
of field characters added with 3.3.9 (December, 2013).
But, since strchr() was used, no error exit was taken.
In the revised 3.3.16 implementation, the strchr() was
replaced with '&w->rc.fieldscur[n]'. This held overrun
to a single position while producing an error message.
So, this commit just moves that logic to a point where
fieldscur is guaranteed to be longer than EU_MAXPFLGS.
Reference(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951335
. revised 3.3.16 validation logic
commit 291d98ee50
. original 3.3.15 validation logic
commit fdb58974e2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When that potential abend at program end was addressed
in the patch shown below, one line of code was removed
in error. That line served to suppress some end-of-job
reports should ATEOJ_RPTSTD or ATEOJ_RPTHSH be active.
So, this patch restores that previously deleted logic.
Reference(s):
. potential SEGV fix, master branch
commit d37f85c269
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit 2e4a594221
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit 0847390b83
Signed-off-by: Jim Warner <james.warner@comcast.net>
In a translator hint, under a caution, a reference was
made to the "next three items". Unfortunately however,
there was one intervening 'item' to which that caution
did not apply. This commit just relocates that 'item'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit duplicates a change to that newlib branch.
However, it should be noted that such a change was not
really necessary under this master branch since proc_t
data remains valid much longer. It is being duplicated
here as documentation only. Below is the original msg.
------------------------------------------------------
This patch will eliminate a bug which is unique to our
newlib branch. It's extremely rare and only happens if
a search ('L'/'&') is initiated during the period when
fields are currently being auto-sized (AUTOX_MODE on).
This bug surfaces as either all zero results for tasks
displayed or a segmentation fault, depending upon what
fields were activated. It is caused by the timing of a
call to the <pids> 'reset' function. When called after
a task refresh, but before do_key(), this bug appears.
So this patch just ensures that 'reset' will be called
after do_key() & before the tasks have been refreshed.
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit 7bd4f0b6d7
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit e1f419737f
Signed-off-by: Jim Warner <james.warner@comcast.net>
All TIC delta fields are checked for possible negative
results and set to zero when found. This is done so as
to protect against potential anomalies which depend on
kernel version and/or toggling cpus offline or online.
[ it's probably unnecessary with the latest kernels, ]
[ except for iowait. documentation suggests it might ]
[ decrease which would then create a negative delta. ]
The same approach is employed for most of the 'system'
deltas (ctxt, intr & procs_created). However, with two
of the fields (procs_blocked & procs_running) negative
results were allowed. But it now seems such a division
is unwise so this patch will allow all to go negative.
[ rather than force any 'system' delta value to show ]
[ what's logical, we'll now let all reflect reality. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just standardizes/normalizes the whitespace
employed within a couple of nearly identical #defines.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In a translator hint, under a caution, a reference was
made to the "next three items". Unfortunately however,
there was one intervening 'item' to which that caution
did not apply. This commit just relocates that 'item'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previous release incremented the age instead of incrementing the
revision. The age can only increment if revision (internal changes
only) or current (API changes) also increments.
A C:R:A of 8.0.2 means its the latest revision of 8.0 library and
any binary linked against 8.0 will work. This is our third revision
of the 8.0 library.
References:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
