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>
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>
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>
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>
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>
While a Debian bug report referenced below was limited
to the 'eip' and 'esp' fields, this patch also extends
address width adaptations to some other addresses too.
[ and, we do so in a far less invasive manner than a ]
[ redhat approach shown below adding two new fields! ]
Reference(s):
. new debian bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846361
. old redhat solution
https://bugzilla.redhat.com/show_bug.cgi?id=244152
Signed-off-by: Jim Warner <james.warner@comcast.net>
No longer will ps print nwchan as 'ffffff', '-' or '1'
since the proc/PID/stat wchan field didn't represent a
real address anyway. Rather, the field will henceforth
output a dash ('-'), the ps customary 'not available'.
That man document was also tweaked to better represent
actual behavior. An asterisk ('*') was never shown for
threaded tasks and that dash ('-') usually didn't mean
running tasks (sometimes associated with permissions).
Signed-off-by: Jim Warner <james.warner@comcast.net>
dlopen() functionality is only used when SELinux support is enabled, so
<dlfcn.h> only needs to be included when ENABLE_LIBSELINUX is
defined. This fixes the build in configurations where <dlfcn.h> is not
available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch is the response to changes in <pids> types.
These additional modifications were also incorporated.
. ps -------------------------------------------------
pr_wname was eliminated as it just duplicated pr_wchan
pr_wchan referenced WCHAN_ADDR in error, vs WCHAN_NAME
pr_nwchan referenced WCHAN_NAME, not proper WCHAN_ADDR
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch we've completed a progression toward a
standard approach to naming conventions which follows:
* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------
* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------
* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE
[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------
* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------
* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ plus we also play catch up on some earlier changes ]
[ that impacted skill.c, after using --enable-skill! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'new' function requires a NULL context pointer, so
when existing code worked, it was just a case of luck.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For some time with enough compilier flags I have watched the
following warning drift by:
ps/output.c: In function ‘pr_nwchan’:
ps/output.c:658:41: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
return snprintf(outbuf, COLWID, "%x", (unsigned)rSv(WCHAN_NAME, str, pp));
nwchan is supposed to be the address of where the process is sleeping,
not the name. Besides %x is a hex number not a string hence the warning.
nwchan now prints the address, in hex and GCC is happy.
This patch just brings *most* other programs into line
with those changes recently made in the <meminfo> API.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch brings the ps program (very small impact) &
that vmstat program (major impact) into agreement with
the new <stat> API. In the case of the latter guy, the
many separate calls to 'get' should be replaced by one
single 'select' call obtaining all data in one stroke.
[ but, i was too tired to undertake that enhancement ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
escaped_copy(): only appears in ps, moved to ps/output.c
escape_strlist() only used in escape.c made static
escape_command() used in library, made internal
procps.h no longer includes escape.h
escape_str() used by library and ps so needs to be exported
definition put into procps.h including the odd define required.
Far from ideal to have it this way, will look at it another time
to have it all in, all out or split nicer so its not in the API;
perhaps a lib/ file?
The includes used to define a lot of things a library include
should not. It was also a bit messy what was exposed in the library
and what was not.
get_pid_digits -> procps_pid_length and exported correctly
MALLOC attribute move into relevant .c files
NORETURN attribute moved to relevant .c, not used in library
PURE attribute removed, it wasn't used
KLONG/KLF/STRTOUKL were fixed for long, so now just use long
HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT
seems to do the same (opposite) thing.
likely/unlikely removed from most places, its highly debateable
this does anything useful as CPUs have gotten smarter about branches.
Re-arranged the includes, ALL external programs should just #include
<proc/procps.h> then proc/procps.h includes headers for files that
have exported functions. procps.h and the headers it includes should
not use items that are not exportable (e.g. hidden functions or
macros) they go in procps-private.h
If SELINUX is enabled but the machine is using another MAC system
(like apparmor), ps will fallback to just parsing
"/proc/%d/attr/current", otherwise the label/context would not
be properly displayed in that case.
References:
https://bugs.debian.org/786956
Signed-off-by: Craig Small <csmall@enc.com.au>
[ but stay tuned! there is a commit coming soon that ]
[ represents a rather major internal redesign, which ]
[ was prompted by the ps and top adaptation testing. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The cgroup field while shown as a vector is a concatenated
string, so alot of the complexity of sorting and displaying
has gone.
This change simplifies the cgroup sorting and adds display
and sorting for the name attribute of the cgroup, if found.
Signed-off-by: Craig Small <csmall@enc.com.au>
Ported-by: Jim Warner <james.warner@comcast.net>
From original:
commit 0ee090ae16
With the conversion to the new <pids> interface, a few
comments (only) are being adjusted, as detailed below.
. Escapes '\' crept into some comments containing '|'.
. For consistency, add '.' dot qualifier to a comment.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit represents the ps transition to the <pids>
'stacks' interface. While an effort to minimize impact
on existing code was made (as with a disguised proc_t)
the changes were still extensive. Along the way, a few
modifications beyond simply conversion were also made.
------------------------------------------------------
Here's a brief overview the design of this conversion:
. The need to satisfy relative enum requirements could
not easily have been made table driven since any entry
in the format_array might require several <pids> items
in support. So I decided to allow every print function
to contribute its own relative enums once the decision
as to exactly what will be printed had been finalized.
. A similar approach was taken for sorting, since it's
possible to have sort keys that will not be displayed.
Here, I relied on the existing print extensions above.
. In summary, just prior to printing ps walks thru two
lists one time (the format_list & sort_list) and calls
each print function. That function does not print, but
sets its required enum if necessary. Later, when those
same functions are called repeatedly for every printed
line, the only overhead will be an if test and branch.
------------------------------------------------------
Below is a summary of major changes beyond conversion:
. Sorts are now the responsibility of the library. And
therefore the total # of sortable fields substantially
increased without effort. Additionally, several quirky
fields remain as sortable, even though they can't ever
be printed(?). Surely that must make sense to someone.
[ while on this subject of sort, please do *not* try ]
[ to sort old ps on 'args'. or better yet, if you do ]
[ try that sort, see if you can determine his order, ]
[ without peeking at the source. that one hurts yet! ]
. All logic dealing with the old openproc flags and ps
struct members known as 'need' have been whacked since
that entire area was solely the new library's concern.
. Remaining malloc/calloc calls to stdlib were changed
to xmalloc/xcalloc from our own include/xalloc.h file.
None of the replaced calls ever checked return values.
[ be aware that 2 minor potential memory leaks exist ]
[ depending on command line arguments. no attempt is ]
[ made to free dynamically acquired format/sort node ]
[ structures upon return; a conscious design choice. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Functions related to namespaces were half-in half-out of the
procps library and didn't fit the standard naming scheme.
While struct { long ns[x]} is a bit clunky, its the only way
to "lock in" x. The alternative is to use ns_* variables.
This work was needed before pgrep could be converted.
In addition to that text shown below the line which is
common to several commit messages, this patch contains
several minor changes with lessor impact upon the API:
. A call to procps_stat_read_jiffs() has been added to
those jiffs functions carrying the 'fill' nomenclature
to parallel like functions in some of our other files.
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
. Standard copyright boilerplate was added in .c file.
. The header file follows the conventions of indenting
(by 4 spaces) those parameters too lengthy for 1 line.
------------------------------------------------------
. 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>
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>
