In addition to that text shown below the line which is
common to several commit messages, this patch contains
the following additional change without an API impact:
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
------------------------------------------------------
. The former 'chains' have now become 'stacks' without
the 'next' pointer in each result struct. The pointers
initially seemed to offer some flexibility with memory
allocations and benefits for the library access logic.
However, user access was always via displacement and a
a statically allocated chain was cumbersome to define.
. An enumerator ending in '_noop' will no longer serve
as a fencepost delimiter. Rather, it has become a much
more important and flexible user oriented tool. Adding
one or more such 'items' in any items list passed into
the library becomes the means of extending the 'stack'
to also include user (not just library) data. Any such
data is guaranteed to never be altered by the library.
. Anticipating PID support, where many different types
must be represented in a result structure, we'll adopt
a common naming standard. And, while not every results
structure currently needs to reflect disparate types a
union will be employed so the same dot qualifier ('.')
can be used consistently when accessing all such data.
Signed-off-by: Jim Warner <james.warner@comcast.net>
While meminfo does implement only the singular version
of 'xxxx_chain_fill', it was wrong to limit the 'read'
to the plural version (only) within our new slabs API.
This kind of inconsistency will only spell trouble for
future users of the new libprocps API. So, this commit
will mean that any form of xxxx_chain(s)_fill function
also includes a 'read', whereas xxx_getchain does not.
Reference(s):
commit aab537bc13http://www.freelists.org/post/procps/newlib-interfaces
Signed-off-by: Jim Warner <james.warner@comcast.net>
With a little help from smatch, this commit eliminates
some inappropriate code. Also some programmer comments
were (barely) improved (i hope) in some small measure.
Reference(s):
smatch: 406 procps_meminfo_chain_fill() warn: variable dereferenced before check 'chain' (see line 403)
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch, we will be close to an implementation
which will be needed when accommodating tasks/threads.
The following explanation was from an earlier message:
The slabtop requirements are similar to those of PIDs.
One must accommodate the variable number of slab nodes
(PIDs) while also accepting different data (char * and
unsigned long). Furthermore, some generalized means to
sort all that acquired stuff must somehow be provided.
------------------------------------------------------
So this patch expands the API to provide dynamic chain
allocation plus allow sorting of those dynamic chains.
While specific to slab needs (nodes, not global stats)
it is not too early to begin to think of newlib chains
as the opaque replacement for a deprecated old proc_t.
Better yet, any newlib chain is inherently variable in
length, something the old proc_t couldn't claim to be.
Of course, as we get to PIDs we'll want to grow/shrink
chains (easily accomplished with a special item enum).
And we'll want to grow/shrink those **head arrays too.
But these minor details don't seem insurmountable now.
Signed-off-by: Jim Warner <james.warner@comcast.net>
An earlier approach to meminfo chaining, referenced in
the patch shown below, represents the first baby steps
toward the goal of some generalized approach with PIDs
processing. However, statically allocating a chain for
each task or thread is totally impractical. And, while
a single chain could serve all PIDs, that would mean a
separate call to our library for each running process.
This commit is intended as the next evolutionary step,
dynamically allocating some 'result' chains to contain
as many or as few 'items' as a caller wishes. In other
words, holding only those 'items' of current interest.
This is the kind of service useful for both top and ps
programs if we finally get around to /proc/<PID> data.
Reference(s):
commit c3fd7473c5
Signed-off-by: Jim Warner <james.warner@comcast.net>
This was Craig's original patch, referenced below, but
it was never pushed to newlib. It has now been rebased
on top of some diskstat stuff to serve as a beginning.
The original effort was perfectly serviceable (after a
memory leak was fixed) but the approach would not have
served future PID needs when that proc_t went bye bye.
The slabtop requirements are similar to those of PIDs.
One must accommodate the variable number of slab nodes
(PIDs) while also accepting different data (char * and
unsigned long). Furthermore, some generalized means to
sort all that acquired stuff must somehow be provided.
So I wanted to try a different approach that seemed to
hold potential for satisfying future top and ps needs.
Subsequent commits will make that attempt, building on
Craig's original patch whose commit msg appears below.
------------------------------------------------------
All of the /proc/slabinfo related calls have been changed
here. They follow the same procps_slabinfo_* format.
Made both the slabtop and vmstat programs use the new
API as one was using the old one and one was just sort
of trying to do its own thing.
Sorting of slabnodes is also possible via the library.
Reference(s):
http://www.freelists.org/post/procps/Sorting-slabsprocesses,3http://www.freelists.org/post/procps/library-rework-slabinfo-calls
Signed-off-by: Craig Small <csmall@enc.com.au>
Signed-off-by: Jim Warner <james.warner@comcast.net>
The calls for reading diskstat have been moved out of
sysinfo and into new files diskstat.[ch] These new
library calls follow the standard pattern for the
new libprocps.
vmstat is updated to use the new API and also got
the weighted IO time added.
vmstat -p previously would only show partitions, not
disks. There does not appear to be any good reason to
artifically deny a user to use this command on a disk,
rather than a partition so this restriction was lifted.
I also realised using int for devid means you can send
the library negative numbers, the index uses unsigned int.
Other similiar calls will need to be fixed too.
Signed-off-by: Craig Small <csmall@enc.com.au>
This is actually a systemcall getpagesize(2) or it is defined
in configure using a variety of methods, including a default
hard coded value as a last resort.
There is no need to have this in libprocps
The new library meminfo & vmstat modules use structure
names for their context which exactly mirror the names
of the very /proc/ files whose particulars they yield.
The one exception to this rule was the readstat module
whose struct was named statinfo yet the file was stat.
This commit simply renames that structure (only) so as
to hopefully establish such a naming convention as our
standard going forward. And, it's makes good symmetry.
[ this module's name itself is just perfect as it is ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier attempt at protecting these functions from
already freed memory worked just fine until the memory
was, in fact, reused by the OS. At that point, the ref
count would most likely fail an existing a test for 0.
So this commit will take control of the 'info' pointer
and force it to NULL when a reference count reaches 0.
Plus, since it makes little sense returning an address
that a caller already has, henceforth we will return a
reference count out of the 'ref' and 'unref functions.
Reference(s):
commit 74beff80ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
There was not a way I could see to support top's needs
for cpu information with the new 'chained' provisions.
The sheer quantity of such data plus the unpredictable
number of potential processors suggested a totally new
approach was warranted while keeping internals opaque.
So this patch introduces two new structures solely for
use by potential callers (as seen in the API). They're
responsible for providing them to the library which is
then responsible for filling them with requested data.
The top program will continue to provide numa support,
without involving the library in any of those details.
[ not to mention all the 'dl' and 'stderr' numa crap ]
With this transfer of the cpu tics duty to our library
the provision associated with the CPU_ZEROTICS #define
could not initially be migrated. The commit referenced
below suggests it may have lost its importance. In any
case such logic may yet be incorporated in the future.
But for now, that #define has been completely removed.
Reference(s):
commit ee3ed4b45e
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since we are not using a higher level standard C fopen
all of the read requests were made signal sensitive as
that can result in a 'temporarily' failed i/o request.
Also, protection against some user calling the 'unref'
function on already free memory has been incorporated.
This will protect us from some nasty 'Abort' surprise.
Signed-off-by: Jim Warner <james.warner@comcast.net>
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch mostly just eliminates darn tab characters.
Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.
The following names were changed to more closely match
meminfo.c or provide a certain symmetry. Unfortunately
that also impacted some other pgms which were updated.
. 'procps_stat_get' evolved into 'procps_stat_get_sys'
. 'procps_stat_info' is now known as 'procps_statinfo'
[and just a little trailing whitespace was eliminated]
Signed-off-by: Jim Warner <james.warner@comcast.net>
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch fills in some missing fields which have top
dependencies. Additionally, I've tried to mirror those
calculations Jaromir added for release 3.3.10. The one
calculation that remains missing is 'available' memory
for some kernels. For this API, we'll use a fall-back.
Lastly the lxc safeguards which were recently added to
the old procps library were incorporated here as well.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch mostly just eliminates darn tab characters.
Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Created new set of functions for meminfo related calls. Liked the
format of that better so changed vmstat around so the look similar.
Missed the makefile change for uptime so added it in now.
Removed the printf_uptime, binaries can do printf easily enough.
sprint_uptime split into two as there wasn't a lot of common
code
sprint_uptime(): old style uptime line
sprint_uptime_short(): short new style "uptime -p"
Hertz_hack needed this, no sane system uses the code (I think)
so just assume 100 like we do in FreeBSD.
Use the standard libc declarations.
For protecting the headers for C++ procps used to have its
own defines, this change makes them use the standard libc ones.
getstat() -> procps_stat_*
vminfo() -> procps_vmstat_*
These two components of the library now use the newer version of
the API with less exposed global variables. The old methods are
there for now.
Signed-off-by: Craig Small <csmall@enc.com.au>
wish folks (craig) would use these in their .gitconfig
[core]
whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
whitespace = warn
Signed-off-by: Jim Warner <james.warner@comcast.net>
Added function procps_linux_version() which used to be an
exported integer instead. Also changed the method of obtaining
the linux version (more correctly the os release) to use a specific
procfs entry. This works for both Linux and FreeBSD.
This patch will bring three of our man pages into line
with the recent refactor of the libprocps wchan logic.
[ and also eliminates more damn eol whitespace which ]
[ snuck in our repo with the commit referenced below ]
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
commit cf4788c28d
Signed-off-by: Jim Warner <james.warner@comcast.net>
Several Debian based distributions were recently found
to have omitted a kernel configuration option that had
the effect of rendering /proc/#/stat and /proc/#/wchan
useless for providing any 'sleeping in function' info.
That problem also prompted a reevaluation of the whole
approach to wchan matters which had grown increasingly
complex as our library evolved over the last 13 years.
The net result was a decision to rely on /proc/#/wchan
which arrived along with the 2.5 kernel. This then let
us vastly simplify the internal code plus the external
interface which will benefit both the top and ps pgms.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11https://lkml.org/lkml/2008/11/6/12https://bugs.debian.org/711592
Signed-off-by: Jim Warner <james.warner@comcast.net>
It doesn't make any sense to have the binary version strings
embedded into the library. The version strings are defined
already either in the Makefile or in include/c.h
This commit adds a lxc container name to every proc_t.
If a process is not running in a container, then a '-'
will be provided, making such a field always sortable.
Unlike other proc_t character pointers, lxc containers
will find many duplicate shared values. So rather than
strdup 'em (with a later free required upon reuse), we
try to keep track of those already seen and share that
address among all tasks running within each container.
We rely on the lines in the task's cgroup subdirectory
which may initially seem somewhat unsophisticated. But
the lxc library itself uses a similar approach when it
is called to list active containers. In that case, the
/proc/net/unix directory is parsed for the '/lxc' eye-
catcher, with potential complications from hashed path
and names that are too long (something we don't face).
[ too bad docker abandoned lxc - our commit won't do ]
[ anything for the users of those kind of containers ]
Reference(s):
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1424253https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1424253
Signed-off-by: Jim Warner <james.warner@comcast.net>
Under a lxc container, the /proc/meminfo 'MemFree' and
'MemAvailable' amounts will be equal, unless memory is
being limited via cgroups in which case 'MemAvailable'
could exceed that for 'MemTotal'. And when a container
has been nested, there exist additional memory quirks.
A program might then display used or available amounts
greater than total memory (assuming unsigned honored),
or negative values (should a signed cast be employed).
This anomaly primarily impacted the top and free pgms.
Thus, two simple sanity checks have been introduced to
avoid any illogical kb_main_available or kb_main_used.
( Busybox top & free also display anomalous although )
( different results when running in a lxc container. )
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153817
Signed-off-by: Jim Warner <james.warner@comcast.net>
This will be required for subdir-objects, otherwise automake will have
problems with more than one Makefile.am having rules to build the same
files.
Tested that it builds and both `make check` and `make distcheck` work.
Tested `make install` and compared the tree with the one installed
before this commit, both installed the binaries to the same locations.
The binaries are also in the same location in the build tree (for
instance, ps/pscommand is still there.)
Checked the binaries for the correct libraries linked into them. Binary
sizes matched before and after this change.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is required for out-of-tree build to work, since many source files
include e.g. proc/*.h which is not under the include/ directory.
Tested that `make distcheck` starts working after this patch.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Let's not report zero for kb_main_available when older
kernels don't have MemAvailable. Instead, if we simply
duplicate the 'free' amount we can avoid all ancillary
problems, such as those involving top's graphing mode.
Reference(s):
http://www.freelists.org/post/procps/kb-main-available-etc,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just ensures recalculation of some amounts
for iterative processes, like top. It also trades some
repeated runtime calls to sysconf for a one time cost.
Reference(s):
http://www.freelists.org/post/procps/systemd-support-to-library,7
. fall-back calculations
commit b779855cf1
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ plus remove just a little darn trailing whitespace ]
Reference(s):
. systemd migrated to library
commit 9d8ad6419f
. added library documentation
commit a74fb8fade
Signed-off-by: Jim Warner <james.warner@comcast.net>
The stderr message regarding ELF notes appears on some
systems (openSUSE-13.1 for example) but I have not yet
isolated why. Since at startup we go on to determine a
Hertz value the old fashion way, this patch just turns
off the useless message until the cause is understood.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit adds support for fallback calculation
of the MemAvailable field if not exported by the
kernel. The MemAvailable field appeared in kernel
3.14, but it's possible to calculate it from other
fields since 2.6.27 (splitLRU changes).
Nowadays the usernames can be 32 characters long
(typically OpenShift usernames use the whole length)
and the old limit was preventing us from processing
them correctly.
The macro change affects the proc_t structure size.
This commit adds a new switch -a/--available that
appends a new column called 'available' to the
output. The column displays an estimation
of how much memory is available for starting
new applications, without swapping. Unlike the data
provided by the 'cached' or 'free' fields, this
field takes into account page cache and also that
not all reclaimable memory slabs will be reclaimed
due to items being in use.
The subtraction was marked as reinforcing the misconception,
that memory in the page cache can be considered free.
The Cached value is not a sum of page cache and tmpfs,
as the tmpfs memory lives in the page cache and therefore
it's an inseparable part of it.
tmpfs has become much more widely used since distributions use it for
/tmp (Fedora 18+). In /proc/meminfo, memory used by tmpfs is accounted
into "Cached" (aka "NR_FILE_PAGES",
http://lxr.free-electrons.com/source/mm/shmem.c#L301 ).
The tools just pass it on, so what top, free and vmstat report as
"cached" is the sum of page cache and tmpfs.
free has the extremely useful "-/+ buffers/cache" output. However, now
that tmpfs is accounted into "cached", those numbers are way off once
you have big files in /tmp.
Fortunately, kernel 2.6.32 introduces "Shmem", which makes tmpfs memory
usage accessible from userspace (
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b02108ac1b3354a22b0d83c684797692efdc395 ).
This patch substracts Shmem from Cached to get the actual page cache
memory. This makes both issues mentioned above disappear. For older
kernels, Shmem is not available (hence zero) and this patch is no-op.
Additionally:
* Update the man pages of free and vmstat to explain what is happening
* Finally drop "MemShared" from the /proc/meminfo parser, it has been
dead for 10+ years and is only causing confusion ( removed in kernel
2.5.54, see
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=fe04e9451e5a159247cf9f03c615a4273ac0c571 )
vmstat -d or vmstat -p would crash mysteriously under different
circumstances. The problem was eventually tracked down to /sys not
being mounted which meant is_disk() always returned false.
The partition would then be attempted to be linked to a non-existent
disk causing a segfault.
vmstat will now not link to a disk if none exists.
The change in testing will skip those tests when /sys/block doesn't
exist.
Many thanks to Daniel Schepler for his analysis and suggestions.
Bug-Debian: http://bugs.debian.org/736628
Under some circumstances the ksh shell doesn't fork new processes
when executing scripts and the script is interpreted by the
parent process. That makes the execution faster, but it means
ksh needs to reuse the /proc/PID/cmdline for the new script name
and arguments while the file length needs to stay untouched.
The fork is skipped only when the new cmdline is shorter than
the parent's cmdline and the rest of the file is filled
with '\0'. This is perfectly ok until we try to read the cmdline
of such process. As the read_unvectored() function replaces
all zeros with chosen separator, these trailing zeros are replaced
with spaces in case of the ps tool. Consequently it appends
multiple spaces at the end of the arguments string even when these
zeros do not represent any separators and therefore shouldn't
be replaced.
With this commit the read_unvectored() function skips the
replacement of trailing zeros and separates valid content only.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1057600
While 'invisible' thread subdirectories are accessible
under /proc/ with stat/opendir calls, they have always
been treated as non-existent, as is true with readdir.
This patch trades the /proc/#/ns access convention for
the more proper /proc/#/task/#/ns approach when thread
access is desired. In addition some namespace code has
been simplified and made slightly more efficient given
the calloc nature of proc_t acquisition and its reuse.
Reference(s):
commit a01ee3c0b3
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previously the shared memory column was always zero
for 2.6 series kernels (and later) due to the fact,
that the value was taken from the MemShared entry
that disappeared with 2.6 series kernels.
Later a new Shmem entry appeared in the /proc/meminfo
file and the 'shared' column now displays either
the MemShared or the Shmem value (depending on their
presence - the presence is mutually exclusive).
If none of the two entries is exported by the kernel,
then the column is zero.
An unpleasant thing happened when I comitted the shmem support
for the 'free' tool. We already had a merge request from
Adrian Brzezinski in the queue, doing exactly the same.
As Adrian deserves credits, I'm reverting the change
and re-applying with the next commit in order to make
him a part of the project history.
Previously the shared memory column was always zero
for 2.6 series kernels (and later) due to the fact,
that the value was taken from the MemShared entry
that disappeared with 2.6 series kernels.
Later a new Shmem entry appeared in the /proc/meminfo
file and the 'shared' column now displays either
the MemShared or the Shmem value (depending on their
presence - the presence is mutually exclusive).
If none of the two entries is exported by the kernel,
then the column is zero.
It seems in some cases procs_running field of /proc/stat can contain 0 even if vmstat itself is running. At least this can be reproduced on Linux 3.9.3 compiled with BFS scheduler.
Since getstat() decrements value of procs_running by 1, we get overflow:
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 667732 918996 57376 911260 21 30 36 40 98 45 14 82 4 1
4294967295 0 667728 916716 57376 911264 8 0 8 0 1958 3733 28 7 65 1
0 0 667700 915996 57376 911416 24 0 152 0 1735 3600 23 5 71 1
4294967295 0 667700 915872 57376 911392 0 0 0 0 1528 3165 21 4 76 0
Function getbtime() currently makes the assumption that btime==0 equals
btime not being present in /proc/stat. This is not quite accurate, as
timestamp 0 is, in fact, also a valid time (Epoch), and /proc/stat may
report it as such.
We introduce a flag to indicate whether btime was found in /proc/stat.
In this way, btime==0 becomes a valid case, provided /proc/stat
actually reports this as the boot time.
procps can still detect the case of btime actually not being reported
by the kernel.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
One recent patch to dynamic buffer management involved
over-allocating the buffer increase to lessen calls to
xrealloc. That was successful, but the actual increase
amount did not attempt to optimize size or alignments.
With this commit, we'll copy an approach recently used
by the top program and round up buffer sizes to 1 KiB.
More importantly, while buffers are quickly reaching a
KiB optimum multiple, no memcpy will ever be employed!
To illustrate just how effective top's algorithm would
be, just change the initial and subsequent allocations
from the current 1024 bytes to just a single byte then
add an fprintf. Those one byte reallocations while on
the way to optimum buffer size will be a one-time cost
and won't represent any recurring performance penalty.
( gosh, that top program *must be* one fart smeller, )
( or was that a smart feller, i can't remember which )
Reference)s):
commit 6d605f521c
commit a45dace4b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Each process in Linux has a /proc/<pid>/ns directory which contains
symbolic links to pipes that identify which namespaces that process
belongs to. This patch adds support for ps to display that information
optionally.
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
An earlier commit attempted to cleanse our environment
of all useless trailing whitespace. But the effort did
not catch 'empty' lines with a single space before ^J.
This commit hopefully finishes off the earlier effort.
In the meantime, let's pray that contributors' editors
are configured so that such wasted crap is disallowed!
Reference(s):
commit fe75e26ab6
Signed-off-by: Jim Warner <james.warner@comcast.net>
When utility buffers were introduced for file2str read
requests, a subtle change was inadvertently introduced
such that a read of zero no longer returns a -1 value.
This commit ensures that zero bytes read returns a -1.
And although the solution differs from a merge request
submitted by sergey.senozhatsky@gmail.com, a thank you
is offered for revealing this potential abend problem.
References(s):
commit a45dace4b8http://gitorious.org/procps/procps/merge_requests/11
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Craig Small <csmall@enc.com.au>
When dynamic buffers were recently introduced for read
of the status, stat and statm subdirectories one extra
call to read() was required for end-of-file detection.
This patch avoids most all such extra calls to read().
Additionally, the frequency of memory reallocations is
reduced by overallocating each increase more than 25%.
Reference)s):
commit a45dace4b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Craig Small <csmall@enc.com.au>
Internal changes to libproc means the revision number
is incremented. This does not mean an ABI or API change has
occured, we just do the stuff under the covers better or in this
case reduce the compile warnings mainly.
See Jim, I do read the commit messages :)
readproc.c: In function 'stat2proc' :
readproc.c:516: warning: use of assignment suppression and length modifier together in gnu_scanf format
readproc.c:516: warning: use of assignment suppression and length modifier together in gnu_scanf format
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
A recent Debian bug report, dealing with release 3.2.8
and its even more restrictive buffer sizes (1024) used
in stat, statm and status reads via file2str calls, is
a reminder of what could yet happen to procps-ng. Size
needs are determined by kernel evolution and/or config
options so that bug could resurface even though buffer
size is currently 4 times the old procps-3.2.8 limits.
Those sizes were raised from 1024 to 4096 bytes in the
patch submitted by Eric Dumazet, and referenced below.
This patch makes libprocps immune to future changes in
the amount of stuff that is ultimately found in a proc
'stat', 'statm' or 'status' subdirectory. We now trade
the former static buffer of 4096 bytes for dynamically
allocated buffers whose size can be increased by need.
Even though this change is solely an internal one, and
in no way directly affects the API or the ABI, libtool
suggests that the LIBprocps_REVISION be raised. I hope
Craig remembers to do that just before a next release.
We don't want a repeat of the procps-ng-3.3.4 boo-boo,
but with no API/ABI impact that probably can't happen.
p.s. A big thanks to Jaromir Capik <jcapik@redhat.com>
who reviewed my original version and, of course, found
some of my trademark illogic + unnecessary code. After
his coaxing, he helped make this a much better commit.
Reference(s):
. procps-3.2.8
http://bugs.debian.org/702965
. allow large list of groups
commit 7933435584
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reviewed by: Jaromir Capik <jcapik@redhat.com>
The entire tree's polluted with inappropriate trailing
whitespace. This commit rids our environment of all of
those useless keystrokes. Unfortunately, it sure ain't
a permanent solution and requires every contributor to
instruct their editor(s) to prevent or eliminate them.
Plus it's strongly recommended we all insert something
like what's shown below to our '.gitconfig' file so as
to provide at least some warnings when we try to apply
any patches (git am) that do contain the #@!%& things!
References(s):
~/.gitconfig excerpt ---------------------------------
[core]
whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
whitespace = warn
--------------------------------- ~/.gitconfig excerpt
Signed-off-by: Jim Warner <james.warner@comcast.net>
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
Fixes error which did not happen always. Changes of being affected by
the bug where greater the more there where pids defined as pmap argument.
The debian bug referral can almost certainly reproduce the problem,
especially when tried multiple times in row.
pmap: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >=
(unsigned long)((((__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) ==
0)' failed.
Reported-by: lee <lee@yun.yagibdah.de>
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688180
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Current linux kernels output no more than 32 groups
in /proc/{pid}/status.
Plan is to increase this limit.
This patch allows ps to not core dump if the buffer used to read status
file was too small.
# ps aux
Signal 11 (SEGV) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
Also increases the size of the buffer from 1024 to 4096, since even with
32 groups we are close to the limit.
cat /proc/12731/status | wc
39 128 961
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
When the maj_delta and min_delta fields were added to
the proc_t, they necessitated some compiler generated
padding bytes.
With this slight reordering, those padding bytes are
no longer generated. And since the original commit
already broke the library ABI, now is an opportune
time to correct that misalignment.
Reference:
commit 7753bd1004
Signed-off-by: Jim Warner <james.warner@comcast.net>
Both options provide more information about a process using -X and -XX
flags. The data comes from /proc/PID/smaps so it may vary.
Signed-off-by: Craig Small <csmall@enc.com.au>
In preparation for top scrollable environment display,
the new flag PROC_EDITENVRCVT was added to mirror the
existing single vector string handling for cgroup and
cmdline.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The control group hierarchies for any particular task
could conceivably grow quite large. However, the
library might impose an arbitrary limit of 1024 bytes
via fill_cgroup_cvt.
Two utility buffers of 128 KiB each were already
available for command line use. This commit simply
trades the smaller 1024 byte stack based buffers for
those much larger existing ones. Thus, truncation
can be avoided with no additional run-time costs.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some inconsistencies have emerged during development
of support for these relatively new proc_t fields.
For example, a PROC_FILLCGROUP flag (via file2strvec)
could return NULL in cgroup whereas PROC_EDITCGRPCVT
(via fill_cgroup_cvt) *almost* guaranteed a return
address (as is true for PROC_EDITCMDLCVT and cmdline).
But even PROC_EDITCGRPCVT could return NULL if the
kernel version was less than 2.6.24. Then with NULL
ps would display a "-" while top would show "n/a".
And while unlikely, with the PROC_FILLSTATUS flag (via
status2proc) a NULL supgid address was theoretically
possible and both ps and top would then show "n/a".
This commit standardizes the following usage:
. PROC_FILLSTATUS (via status2proc)
guarantees a valid supgid address
representing either a true comma
delimited list or "-"
. PROC_FILLCGROUP plus
PROC_EDITCGRPCVT (via fill_cgroup_cvt)
guarantees a cgroup single vector
representing either a true control
group hierarchy or "-"
And as was true before, the following remains true:
PROC_FILLCOM or
PROC_FILLARG (via file2strvec)
may return a NULL cmdline pointer
. PROC_FILLCGROUP (via file2strvec)
may return a NULL cgroup pointer
. PROC_FILLCOM or
PROC_FILLARG plus
PROC_EDITCMDLCVT (via fill_cmdline_cvt)
guarantees a cmdline single vector
representing either a true command
line or a bracketed program name
. PROC_FILLSTATUS plus
PROC_FILLSUPGRP (via supgrps_from_supgids)
guarantees a valid supgrp address
representing either a true comma
delimited list or "-"
Signed-off-by: Jim Warner <james.warner@comcast.net>
There soon will be slab types per cgroup meaning the name of the slab
will have the cgroup name in parathensis after the slab name. This
minor change increases the slab name size to cater for this.
Signed-off-by: Craig Small <csmall@enc.com.au>
