When several obsolete linux-2.6 fields were eliminated
and ps responded in the commit referenced below, there
was one reference overlooked. So, with this commit the
reference to PIDS_ALARM has been whacked at long last.
Reference(s):
. Sep 2016, ps response to removal
commit 86992bb58f
Signed-off-by: Jim Warner <james.warner@comcast.net>
In that commit referenced below, a new field was added
to the ps program which required adding 2 newlib items
together. Such a need is now satisfied by the library.
So, this commit will just adapt ps for that provision.
Reference(s):
commit e782b1d859
Signed-off-by: Jim Warner <james.warner@comcast.net>
The library added smaps_rollup fields in the referenced commit.
This commit exploits the new fields to give pss and uss options.
These options were first proposed back in 2015 by Petr Malat
and, with the library update, they are finally made it into ps.
Why use proportional or unique segment size? It is argued that
these give a better idea of the "real" memory usage of a process.
References:
commit 12543b6c76
issue #112https://www.freelists.org/post/procps/PSS-and-USS-support-for-pshttps://lwn.net/Articles/230975/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The ps.1 manpage incorrectly stated that psr field showed the
processor the process was assigned to. However if the assignment
has changed but the process has not run, then the field doesn't
change.
Some digging by @srikard showed it wasn't the processor assigned
but the last one it was run on. The man page now correctly
describes psr in that way.
References:
procps-ng/procps#187
That snowball, which began as a simple removal of some
brackets, now ends with this third patch restoring the
ability to build our project. It was made necessary by
the renaming (and rearranging) of several enumerators.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the 4 header files removed in the previous patch,
this commit just changes all those obsolete references
to that new consolidated 'misc.h' header file instead.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Form its inception (back in May of 2011), escaped_copy
has always been a flawed function. It does not operate
on 'escaped' strings but instead treats all input as a
regular string incapable of containing utf8 sequences.
As such, it should only be used for strings guaranteed
to NOT embody multibyte characters (like SUPGIDS). For
all other strings, which could contain utf8 stuff, the
correct function should have been that escape_str guy.
So this commit changes nearly every escaped_copy call.
Reference(s):
. May 2011, original escaped_copy (cmdline, cgroup)
commit 7b0fc19e9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm not sure if anyone actually uses these things, but if you
selected test fields on the command line ps would crash.
$ ps/pscommand -o _left
Signal 11 (SEGV) caught by pscommand (3.3.11.877-0488).
/home/csmall/Projects/procps/procps/ps/.libs/pscommand:ps/display.c:66: please report this bug
Segmentation fault
Anyway, it doesn't now:
$ ps/pscommand -o pid,_left,_left2,_right,_unlimited 1
PID LLLLLLLL L2L2L2L2 RRRRRRRRRRR U
1 tty7 3270/tty4 59:59 [123456789-12345] <defunct>
With glibc, each time the strftime() function is used (twice per process
in a typical ps -fe run), a stat("/etc/localtime") system call is used
to determine the timezone. Not only does this add extra system call
overhead, but when multiple ps processes are trying to access this
file (or multiple glibc programs using strftime) in parallel, this can
trigger significant lock contention within the OS kernel.
Since ps is not intended to run for long periods of time as a
daemon (during which the system timezone could be altered and PS might
reasonably be expected to adapt its output), there is no benefit to
repeatedly doing this stat(). To stop this behavior, explicitly set the
TZ variable to its default value (:/etc/localtime) whenever it is unset.
glibc will then cache the stat() result.
The referenced commit the comm length was increased from 16 to 64
characters to handle the larger command names for things like kernel
threads.
However most user processes are limited to 15 characters which means
if you try something like ps -C myprogramisbiggerthansixteen this would
fail to match because /proc/<PID>/comm would only be myprogramisbigg
ps now checks the comm length and if it is 15 and if the given match
is 15 or more, it will only match the first 15 characters.
This is also how killall has worked for about a year.
Thanks to Jean Delvare <jdelvare@suse.de> for the note.
Copy of commit from master.
References:
commit 14005a371e
commit psmisc/psmisc@1188315cd0
commit 3e1c00d051
Signed-off-by: Craig Small <csmall@dropbear.xyz>
In that commit referenced below, a promise was made to
revisit an 'escape_str' function in efforts to make it
private to the library. The problem was it's needed by
both ps plus the library which is why it was exported.
So, in an effort to remove it from libprocps.sym, this
patch duplicates all the required code in ps/output.c.
Now, each version can be made private to their caller.
[ along the way we'll use this opportunity to remove ]
[ the 'restrict' qualifiers from function parameters ]
[ while swatting a compiler warning referenced below ]
Reference(s):
. April 2016, most escape functions made private
commit d916d5db86
proc/escape.c: In function `escape_command':
proc/escape.c:182:23: warning: initialization of `const char **' from incompatible pointer type `char **' [-Wincompatible-pointer-types]
182 | const char **lc = (char**)pp->cmdline;
| ^
Signed-off-by: Jim Warner <james.warner@comcast.net>
There was a time when that procps.h file served a more
traditional role. Prior to the commit referenced below
it held just macros plus manifest constants. But, with
that change, such items were replaced with a series of
includes embracing all the library exported functions.
That approach was known to disguise errors which would
have otherwise yielded a compiler warning. And without
such a warning, there was no way to address the error.
So this patch will trade the all inclusive header file
approach for individual includes only where necessary.
Reference(s):
. April 2016, procps.h header file revamped
commit ccb6ae8de1
. Sept 2018, top abandoned use of procps.h
commit a6dfc2382e
Signed-off-by: Jim Warner <james.warner@comcast.net>
A Qualys audit patch, represented in the commit below,
added the _exit() call to our abnormal signal handler.
Unfortunately, that disabled the associated core dump.
This patch restores expected behavior of those signals
whose default produces a core dump file + termination.
Reference(s):
commit 7bd4f0b6d7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previous versions of ps used to only match on the first 15 characters
because that's what the kernel used to provide. Newer kernels have a
longer length for this field so procps has been updated to suit.
References:
procps-ng/procps#101https://bugzilla.suse.com/show_bug.cgi?id=1099091
Unlikely to ever happen, since it would imply a very large string, but
better safe than sorry.
---------------------------- adapted for newlib branch
. now uses 'xmalloc' vs. unchecked stdlib 'malloc'
. the member 'need' was removed from 'format_node'
Signed-off-by: Jim Warner <james.warner@comcast.net>
To avoid an out-of-bounds access at checkoff[tmp]. The strspn() at the
beginning of the function protects against it already, but double-check
this in case of some future change.
Right now, "we _exit() anyway" is not always true: for example, the
default action for SIGURG is to ignore the signal, which means that
"kill(getpid(), signo);" does not terminate the process. Call _exit()
explicitly, in this case (rather than exit(), because the terminating
kill() calls do not call the functions registered with atexit() either).
Before "strlen(outbuf)", if one of the pr_*() functions forgot to do it.
This prevents an out-of-bounds read in strlen(), and an out-of-bounds
write in "outbuf[sz] = '\n'". Another solution would be to replace
strlen() with strnlen(), but this is not used anywhere else in the
code-base and may not exist in all libc's.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
pr_bsdstart(): Replace "strcpy(outbuf," with "snprintf(outbuf, COLWID,"
(which is used in all surrounding functions). (side note: the fact that
many pr_*() functions simply return "snprintf(outbuf, COLWID," justifies
the "amount" checks added to show_one_proc() by the "ps/output.c:
Replace strcpy() with snprintf() in show_one_proc()." patch)
pr_stime(): Check the return value of strftime() (in case of an error,
"the contents of the array are undefined").
help_pr_sig(): Handle the "len < 8" case, otherwise "sig+len-8" may
point outside the sig string.
pr_context(): Handle the empty string case, or else "outbuf[len-1]"
points outside outbuf.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
Signed-off-by: Jim Warner <james.warner@comcast.net>
Enforce a maximum max_rightward of OUTBUF_SIZE-1, because it is used in
constructs such as "snprintf(outbuf, max_rightward+1," (we could remove
the extra check at the beginning of forest_helper() now, but we decided
to leave it, as a precaution and reminder).
The minimum max_rightward check is not strictly needed, because it is
unsigned. However, we decided to add it anyway:
- most of the other variables are signed;
- make it visually clear that this case is properly handled;
- ideally, the minimum max_rightward should be 1, not 0 (to prevent
integer overflows such as "max_rightward-1"), but this might change
the behavior/output of ps, so we decided against it, for now.
Instead, we fixed the only function that overflows if max_rightward is
0. Also, enforce the same safe range for max_leftward, although it is
never used throughout the code-base.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
This strcpy() should normally not overflow outbuf, but names can be
overridden (via -o). Also, check "amount" in all cases.
---------------------------- adapted for newlib branch
. we don't use that 'likely/unlikely' crap in newlib
Signed-off-by: Jim Warner <james.warner@comcast.net>
It is static and not used anywhere.
---------------------------- adapted for newlib branch
. limited to whitespace/formatting differences
Signed-off-by: Jim Warner <james.warner@comcast.net>
We decided not to check the return value of the mprotect() calls,
because they are not vital to the operation of ps.
---------------------------- adapted for newlib branch
. many formatting/whitespace differences
Signed-off-by: Jim Warner <james.warner@comcast.net>
1/ Do not go deeper than the size of forest_prefix[], to prevent a
buffer overflow (sizeof(forest_prefix) is roughly 128K, but the maximum
/proc/sys/kernel/pid_max is 4M). (actually, we go deeper, but we stop
adding bytes to forest_prefix[])
2/ Always null-terminate forest_prefix[] at the current level.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
. a commented out 'debug' line was no longer present
Signed-off-by: Jim Warner <james.warner@comcast.net>
Because there is usually less than OUTBUF_SIZE available at endp.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
. ps no longer deals with the library 'FILL...' flags
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch solves several problems:
1/ Limit the number of characters written (to outbuf) to OUTBUF_SIZE-1
(-1 for the null-terminator).
2/ Always null-terminate outbuf at q.
3/ Move the "rightward" checks *before* the strcpy() calls.
4/ Avoid an integer overflow in these checks (e.g., rightward-4).
May happen if strlen(src) > INT_MAX for example. This patch prevents
escaped_copy() from increasing maxroom and returning -1 (= number of
bytes consumed in dst).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
The SECURE_ESCAPE_ARGS() macro solves several potential problems
(although we found no problematic calls to the escape*() functions in
procps's code-base, but had to thoroughly review every call; and this is
library code):
1/ off-by-one overflows if the size of the destination buffer is 0;
2/ buffer overflows if this size (or "maxroom") is negative;
3/ integer overflows (for example, "*maxcells+1");
4/ always null-terminate the destination buffer (unless its size is 0).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the previous patch concerned an essential change
to avoid dereferencing those NULL pointers, this patch
could be considered optional. For consistency, it just
puts all initialization logic after the setREL macros.
[ plus along the way some inter-function spacing was ]
[ standardized with just a single blank line between ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Under newlib design, ps must loop though all potential
print functions so as to gather the appropriate enum's
while establishing the 'relative' equivalent. The keys
to the setREL/chkREL macros are a NULL 'outbuf' param.
It's imperative that no other functions be called with
that NULL value. Unfortunately, several instances were
found where this was violated. They are now corrected!
Signed-off-by: Jim Warner <james.warner@comcast.net>
These format specifiers are to time & cputime what etimes is to etime.
Signed-off-by: Sébastien Bigaret <sebastien.bigaret@telecom-bretagne.eu>
References:
procps-ng/procps!43
The ps program generally supports multi-byte sequences
in strings representing user and group names. However,
should a multi-byte sequence span the maximum width of
a column, the '+' inserted by ps to signify truncation
will corrupt that sequence, misaligning the text line.
Unfortunately, there's insufficient info returned from
the escape_str function (who calls escape_str_utf8) to
provide a robust response. So, this commit will revert
to the old standby of displaying a number when the '+'
character would've corrupted that multi-byte sequence.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]
proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]
ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]
watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
Signed-off-by: Jim Warner <james.warner@comcast.net>
Aw shucks, not all support for this defunct enumerator
was removed via the commits shown below (but, is now).
[ what remained were just variables named after that ]
[ deprecated/deleted enumerator, but still & all ... ]
[ plus, i have left the doc/libproc.3 file untouched ]
[ since it already appears badly out of date anyway! ]
Reference(s):
. ps references partially purged
commit 66c4024d75
. enumerator purged from library
commit 912075605b
Signed-off-by: Jim Warner <james.warner@comcast.net>
