freeproc was missing from the libproc API which meant while you could
allocate proc structures, you couldn't free them!
Bug-Debian: http://bugs.debian.org/681653
The “.I\-aux” syntax is broken (missing space): as a result, the hyphen
doesn't show up in the man page. Furthermore, according to man(1)
conventions, and in consistency with the rest of the manpage, it should
be bold instead of italic, the attached patch fixes this issue.
Signed-off-by: Craig Small <csmall@enc.com.au>
This potential problem is caused by frequently spawned
and short lived tasks which happen to sort above a row
containing a match from an active Locate request. It's
most likely to be visible when under Forest View mode.
This commit will eliminate a potential duplicated row.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Both of the 'file' and 'pipe' Inspect read buffers are
always 2048 bytes bigger than is actually needed which
provided for some slightly simplified row paint logic.
However, with no real rcfile inspect entries, and thus
operating in 'demo' mode, the allocated buffer is only
2048 bytes total. This can produce a valgrind warning.
This commit simply puts the inspect 'demo' buffer on a
par with other allocated real buffers (an extra 2048).
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
The two extra extended pmap options were not tested previously.
We test against our known process and process 1 which we should
not be able to get data for.
Unfortunately, the tests cannot catch SEGSEGVs but they should.
Signed-off-by: Craig Small <csmall@enc.com.au>
While permissions suggests that /proc/#/smaps contents
are world-readable, in practice this file might not be
available to a non-root process. Whether this is a bug
in the kernel or an intentional design decision really
makes no difference. This commit will protect pmap -X.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit faec340719
Author: Dimitrios Apostolou <jimis@gmx.net>
Date: Thu Sep 27 22:08:04 2012 +1000
Signed-off-by: Jim Warner <james.warner@comcast.net>
In a effort to anticipate a potential future wishlist,
the recent '-o' sort override command line switch will
now support an override of the sort direction as well.
By prepending a '+' or '-' to any valid field name the
user will be able to guarantee a specific desired sort
direction. The '+' forces a high-to-low (normal) order
while a '-' reverses that to yield a low-to-high sort.
Without this addition users would be left to the mercy
of whatever was last specified for Curwin as reflected
in the rcfile or top's default of a high-to-low order.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
The recent change to task area memory scaling was just
a little short of optimum in its consistency and upper
limits. In fact, top could only scale memory fields up
to a maximum of 99.9999 TiB (with VIRT a little more).
While that seems like more than enough it was actually
artificially low, due to an unnecessary decimal place.
So, this commit standardizes both precision and widths
to achieve a minimum amount of scaling beyond the user
requested target plus reclaim some horizontal spacing.
. VIRT & DATA are now 7 bytes wide (not eight and six)
. other memory fields are 6 wide (were formerly seven)
. as before, KiB shows whole numbers only (no decimal)
. MiB, for its precision, shows a single decimal place
. all other memory ranges display three decimal places
The net result is a more homogeneous display with less
forced scaling and the recovery of three lost columns.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s);
http://www.freelists.org/post/procps/top-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will allow user filtering as long as there
is a valid number representing a potential user ID. It
will serve, for example, chroot environments where the
specific user may be unknown to a host, or vice versa.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit was adapted from the openSUSE patch, whose
original comments appear between the --- marker below.
It should be noted, however, that the original changes
were ineffective (wasted) because 'Batch' mode had not
yet been set when signals were being checked and their
handlers established. Thus, SIGHUP was never bypassed.
(of course, only our comments are perfectly justified)
------------------------------------------------------
Do not setup SIGHUP signal handler if we are in the batch mode
Top enables a signal handler for the SIGHUP signal (loss of terminal). While
this makes sense for top's default interactive mode, it doesn't make any sense
for batch mode. If you run top in nohup just to collect data over time and
disconnect top finishes which is not what one would expect.
------------------------------------------------------
Reference(s):
http://www.freelists.org/post/procps/top-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Everyone has either accepted this potential distortion
or patched top to eliminate it. Now, the time has come
to regain some consistency when calculating that %CPU.
We'll now limit such values to: 100.0 * total threads.
And, it took way too long to address this little flaw.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reportshttp://www.freelists.org/post/procps/top-regression-reports,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
The delay interval is kept in the rcfile in a floating
point format and is thus susceptible to changes in the
locale between invocations. So values written as #,###
could not be read if a new locale uses decimal points.
This commit takes control of our own decimal point and
will henceforth make top immune to locale switcharoos.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-has-a-localedpendent-config-file-toprchttp://lists.opensuse.org/opensuse-bugs/2012-12/msg01466.html
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the increased width and precision of memory and %
columns, the proliferation of 0's when there's nothing
to report seems like a distraction versus useful data.
This commit introduces the '0' toggle which can either
display or suppress those zeros. And, like the scaling
states this new state is also preserved in the rcfile.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is an unrequested outgrowth of the earlier
change dealing with summary area memory field scaling.
That user selectable scaling provision is now extended
to include 6 (at present) task oriented memory fields.
The new companion 'e' (lower case) interactive command
has been added and, like the 'E' command, it can cycle
each of the currently displayed memory columns between
KiB through TiB. There are, however, some differences.
Where '+' indicates summary area truncation at a given
radix, task memory fields are automatically scaled for
their column. Thus, not all rows use the same scaling.
And, while summary area field widths were not changed,
the task memory columns were widened in order to offer
more meaningful data when the radix was increased. The
precision is automatically increased in step with each
radix: MiB displays 2 decimal places, GiB 3 and TiB 4.
To compliment that additional precision, both the %CPU
and %MEM fields were widened by 1 column and now offer
precision up to 3 decimal places. But, unique to %CPU,
widening could already have occurred due to the number
of processors in some massively parallel boxes. At any
rate, total extra width for both memory and percentage
fields could amount to twenty (precious) columns more.
So for both the memory and % fields the original width
(along with loss of precision) can be restored via new
compiler conditionals which this commit also provides.
p.s. and it will be rcfile preserved for any restarts!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reports
Signed-off-by: Jim Warner <james.warner@comcast.net>
Earlier this year, the switch from KiB to Mib as shown
in top's summary area was postponed to those occasions
when KiB exceeded 8 digits. In hindsight that may have
moved top in the wrong direction, given the difficulty
of digesting such large numbers of digits at a glance.
This commit adds a new 'E' interactive command used to
cycle the displayed memory amounts ranging from KiB to
TiB. Thus, users can choose the radix they wish shown.
p.s. and it will be rcfile preserved for any restarts!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reports
commit 95f2201730
Author: James Cloos <cloos@jhcloos.com>
Date: Mon Feb 6 00:00:00 2012 -0500
Signed-off-by: Jim Warner <james.warner@comcast.net>
This is doubtless not quite the solution envisioned by
the submitter, but 'V' should probably never have been
used as an alias for 'v' now that we have forest-view.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
Bug-Redhat: https://bugzilla.redhat.com/848290
Signed-off-by: Jim Warner <james.warner@comcast.net>
When 'type' was added to the alternate status line for
the '=' key, the need for the demonstration 'type' was
overlooked. This commit avoids the '(null)' potential.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s);
commit 3b2b9a95e6
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the ps command handles signals with it's own handler, it doesn't create
core files when something wrong happens. The attached patch restores the ps
command ability to create core files by calling the default handler once we
print our custom message. The original RH's workaround masked SIGABRT and
SIGSEGV signals and that would conflict with the original intention of the
custom signal handler and also with the filtering patch I sent in my previous
email. Moreover, this solution generates core for all relevant signals (SIGFPE,
etc.).
Bug-Redhat: http://bugzilla.redhat.com/871825
Bug-Redhat: http://bugzilla.redhat.com/512857
Reference: http://www.freelists.org/post/procps/PATCH-Allow-core-file-generation-by-ps-command-rhbz871825-rhbz512857
Signed-off-by: Craig Small <csmall@enc.com.au>
With the recent inspect search highlight provisions in
place, the lack of highlighting in task based searches
has grown from being only irritating to a real defect.
Thus, this commit introduces parallel functionality to
those searches initiated within a visible task window.
And just as separate inspect searches are possible for
each selection, per window task searches are provided.
However, it should be noted that there are differences
between task based searches and inspect type searches:
* There is no concept of out-of-view data when dealing
. with task rows -- if the data can't bee seen, it has
. not, in fact, been constructed from a proc_t struct.
* While inspect data is output at the character level,
. up to now all task display data was only potentially
. output and it was always based on a complete string.
* With task search highlighting, rows now containing a
. match must be output in pieces and, therefore, can't
. be optimized away like other rows which haven't been
. been altered. This is because top cannot predict the
. the contents of a search string or, how many matches
. might occur in a given row. Short search strings and
. many matches would raise buffer needs geometrically.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit extends Inspect provisions for 'find/next'
to each individual selection. Thus a user can maintain
multiple active searches without having to reissue the
locate command whenever the current selection changes.
To emphasize this feature the View screen now displays
the current active locate string or 'N/A' if inactive.
Such a reminder is important when no found matches are
present on the 1st display page, given that they would
otherwise be apparent via the additional highlighting.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
We have modeled the Inspect search provisions on those
provided by the 'less' pager. With this commit we take
the next step and provide for highlighting any strings
matched (and in view). Of course, top will continue to
adjust the beginning column so as to bring out-of-view
matches into view, while highlighting visible matches.
However, top won't emulate every 'less' behavior since
the following are seen as flaws in the user interface.
* when viewing true binary data, less makes no attempt
. to smooth the right margin by truncating unprintable
. symbols, thus creatng ragged unappealing right edges
* when viewing true binary data, less will always fail
. search requests regardless of surrounding characters
* less refuses to bring out-of-view found matches into
. view by adjusting the left-most column, if necessary
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previously top would warn users if an older version of
an rcfile was about to be overwritten. That's assuming
that RCFILE_NOERR was not defined. This left, however,
other potential rcfile issues or questions unattended.
For example, if a faulty 'inspect' redirected echo had
overwritten all window entries or if the inspect entry
was not 'pipe' or 'file' (actually, just a 'p' or 'f')
then top would silently accept it but look no further.
With this commit top will try to process every inspect
entry, while preserving unrecognized entries. Plus all
other non-fatal rcfile errors will now alert a user to
the potential overwrite when the 'W' command is given.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
The Inspect find algorithm has always been challenging
given the possibility that 'rows' might contain binary
data. Be that as it may, two small changes have proven
to dramatically improve the performance of such scans.
The first involves the case wherein if no match on the
'substring' portion of a row was found, then a pointer
representing the substring was increased by the length
of the search string, not the better/longer substring.
Thus, portions of the substring were always rescanned!
The second performance boost was achieved in this way:
pre-scanning each raw row for just the first character
in the search string now determines if a full match is
even possible. Therefore, repeated unproductive strstr
calls on individual substrings within that row will be
avoided. In a nutshell, 1 'if' with '}' did the trick!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit improves display performance when the user
has scrolled horizontally past the end of a top 'row'.
We can avoid the need to memset our buffer with spaces
and putp those spaces individually by exploiting logic
that already exists. If one '\n' character is inserted
into the buffer instead, the next terminfo string sent
will be Cap_clr_eol achieving exactly the same effect!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
