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>
Fix the build where it seems a code fix for Linux was likely untested
on other systems.
Define SCHED_BATCH in test-schedbatch, for systems that don't have it;
the corresponding RH BZ#741090 patch used the magic value 3 in output.c
anyway.
Bug-Debian: http://bugs.debian.org/677055
The problem is that in ./proc/sysinfo.c uptime(), it is not
considered that the "savelocale" string is overwritten by the
subsequent call to setlocale(). Hence restoring the locale later on
won't work this way. "savelocale" ought to be a copy of the string
pointed to by setlocale()'s return-value.
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=548711
Backported-by: Sami Kerola <kerolasa@iki.fi>
There have been some internal changes to the library, so the revision
will be incremented for this release. There is no ABI or API changes
so its no real impact.
Both these are from [-Werror=format-security]
sig.c:262:5: error: format not a string literal and no format arguments
global.c:517:3: error: format not a string literal and no format arguments
Checking for linux kernel version 2.7.0 is meaningless now when 3.0.0
is out.
Reported-By: Christian Hofstaedtler
Bug-Debian: http://bugs.debian.org/635553
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Clean the global list of symbols contain only functions and variables which
are being called from library. The removed symbols are internal for the
library, which means they can be changed without changes to programs using
the library. This clean up should help incoming libprocps clean up work.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Fix the build warnings:
sig.c:227:5: warning: implicit declaration of function 'toupper' [-Wimplicit-function-declaration]
sig.c:231:3: warning: implicit declaration of function 'isdigit' [-Wimplicit-function-declaration]
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
On non-linux systems, uts.version provides the version of that
specific kernel (FreeBSD or Hurd version, for example) and not the
emulated procfs pseudo version.
On those systems we need to directly read /proc/version and parse the
string. This change replaces Debian patches gnu-kbsd-version and
complain_unmounted_proc patches.
procps automake defines restrict which means the binaries for procps
binaries compile. However external programs may not of defined
restrict which means they will not complie if they include files found
in /usr/include/proc.
Includes from libc6 use __restrict and if is good enough for
them, its good enough for us.
Some of the latest changes to Makefile.am files are missing.
This patch restores the LOCALEDIR variable, among others,
and dispenses with the include directives in the ps/ and top/
subdirectories since they're no longer needed.
err and warn are BSD format but they are not recommended by library
developers. However their consiseness is useful!
The solution is to use some macros that create xerr etc which then
just map to the error() function. The next problem is error() uses
program_invocation_name so we set this to program_invovation_short_name
This is a global set but seems to be the convention (or at least errors
are on the short name only) used everywhere else.
The library used to be called libprocps but it was renamed to make sure
there was only one. However the formatting of the library SONAME has
changed so there cannot be any confusion.
libprocps makes it clear that its a library from this project and not a
set of functions directly on the filesystem.
Re-enable signal number to name string, and other way around,
conversion after it broke at the time when long options where
introduced.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The function will convert a signal number string to a signal name, or
vice a verse. Return value is string, which is an function user is
expected to free after use.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Fix few compiler warnings. Some of these warnings appeared multiple
times, and the listing bellow is more about which sort of errors
where fixed.
devname.c:87:12: warning: comparison of integers of different signs: 'int' and 'unsigned long'
output.c:389:36: warning: passing 'char **const' to parameter of type 'const char *const restrict *' discards qualifiers in nested pointer types
output.c:611:31: warning: comparison of integers of different signs: 'const unsigned long' and 'int'
stacktrace.c:33:37: warning: unused parameter 'signum'
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The devname.h requires readproc.h header which has dev_t. Unless
header is included the includes in program files must be in
correct order. I also added FIXME item to remind that for uid &
gid value int not correct data type but uid_t or gid_t from
pwd.h.
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.
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
