The sysctl now uses getopt_long and has help screen which be user
friendly. Rest of the modernization is left later, since this is
a command is used in scripts, and changing for instance error
printing to use warn & warnx could break stuff.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
These xalloc functions are a private function for the library. If using
programs need them, then they should make their own error reporting or
use a common file.
This commit documents the top search provisons as a
new section entitled:
5d. SEARCHING in a window
It also adds minor unrelated content and tweaks some
miscellaneous formatting and spacing inconsistencies.
A patch from Debian.
Bug-Debian: http://bugs.debian.org/183486
Reviewed-by: Craig Small <csmall@debian.org>
Backported-by: Sami Kerola <kerolasa@iki.fi>
Means we do not follow SCO but less confusion.
A patch from Debian.
Bug-Debian: http://bugs.debian.org/541061
Backported-by: Sami Kerola <kerolasa@iki.fi>
Slackware seems to have this patch, while it is not in use(?) Well,
the upstream procps-ng allows one to disable warnings if that is
wanted. After all having this sort of 'feature' does not cost much,
while lacking it might annoy someone.
A patch from Slackware.
Reference: http://www.ftp.be/packages/slackware/slackware_source/a/procps/procps.nowarning.diff.gz
Backported-by: Sami Kerola <kerolasa@iki.fi>
Conflicts:
proc/ksym.c
Previously the version of libproc always tracked the version of procps.
This doesn't work when other non-procps programs link to the library as
they are always playing catch up.
This change makes the library version independent of the procps version.
It will only be incremented when needed.
Commit a5881b5a4e, addressing
command lines with a trailing space, produced an undesirable
side effect in the fill_cgroup_cvt() function.
This patch restores correct cgroup behavior while still
producing command lines with no trailing space.
There were numerous ps memory allocation inconsistencies.
Some were checked for failure and others were not.
The program was modified to utilize the library memory
rouines which are consistent in dealing with errors.
(a few changes simply removed trailing whitespace)
The smatch error --------------
top.c +1414 calibrate_fields(78) error: buffer overflow 'Fieldstab' 39 <= 39
The code -----------------------
if (P_MAXPFLGS < f) { w->endpflg = i; continue; }
The background -----------------
The enum P_MAXPFLGS is strictly a fencepost and can *never* appear in
the arrays pflgsall or procflgs. Thus it (39th element) cannot be used
in referencing Fieldstab.
However, two enums of higher value (X_XON=40 and X_XOF=41) *can* appear
in those arrays. But the test against the fencepost ensures that those
two enums are *never* used in referencing Fieldstab.
When the analyzer sees the conditional using '<' and not '<='
it reports a false positive.
The source was changed to accommodate the tool's deficiency
With forest view mode under procps-ng-3.3.0, top would catch
a SEGV and exit. The problem was thought to be related to
some linux version 3 anamoly.
In procps-ng-3.3.1, top was protected from abnormal exit and
would display the offending processes with the special orphan
notation '?', instead of the usual artwork.
As it turns out, the problem wasn't with linux and could
surface under a 2.6.xx kernel, The cause was an occasional
abnormal ordering of tid/tgid/ppid which went unresolved
due to a progressive proc table scan in the recursive
function forest_add().
By default the proc table scan now restarts at the beginning.
However, a #define TREE_ONEPASS is provided should one wish
to restore the 3.3.1 behavior with its reduced overhead.
An anomaly would surface whenever the sort column was
made non-display under fields management.
The scroll message would report incorrect x coordinates
and the 'x' toggle would produce an unintentional
horizontal scroll.
This patch forces column highlighting off whenever field
changes are made (as is done for horizontal scrolling).
It also inactivates the 'x' toggle whenever the sort
column is not visible.
This bug has yet to be reported.
