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.
In the procs_refresh() function:
. the proctable scan was simplified
. memory allocation is now much more efficient
. window ppts will usually not now need xrealloc
Now that the library allows for customizing the response to
memory allocation errors, it is no longer necessary for top
to provide its own.
This library extension was necessary since top modifies the
termios structure and there would otherwise be no way to
restore the users tty.
When PROC_FILLARG was used (invoking file2strvec)
command lines contained no trailing space.
When PROC_EDITCMDLCVT was used (invoking read_unvectored)
command lines contained a trailing space.
Now both routes to a cmdline act the same -- no trailing space.
The CodingStyle document suggests programs should allow for
cmdlines of at least 128k. Only the ps program can display
such a cmdline, and only with multiple -w switches.
The library function file2strvec can essentially return
a cmdline of unlimited length. However, the library function
fill_cmdline_cvt used an arbitrary upper limit of 2048 for
buffers automatically allocated on the stack.
This patch raises the fill_cmdline_cvt upper limit to 128k via
dymaically acquired utility buffers ensured by the openproc
function.
It also makes indentation consistent in the openproc function.
There were numerous library memory allocation inconsistencies.
Some were checked for failure and others were not.
All library source modules were modified to utilize the alloc.h
memory rouines which are consistent in dealing with errors.
A callback provision in the form of xalloc_err_handler
(of type message_fn) was added to the alloc module.
This change allowed a program like top, who alters the
termios structure, to override the default fprint(stderr...)
behavior in the event of an error.
The new function xstrdup was also added for symmetry.
Makefile.am testsuite needed to explicitly state the files because while
everything else works, make distcheck fails.
NEWS got updated with the Debian bug number for pgrep -u
There is a race condition between expect script consuming the output
from slabtop. There were a sequences of lines that looked like
^\d+ ... \s*
with the last \s* consuming the first space on the start of the line.
However if the line takes too long to print, then expect stops there and
the space at the start of the subsquent line does not match.
The solution is a \s* at the start ofthe line.
