During the changes to procps_loadavg I didn't set the initial
value for retval, meaning it was a random number.
It is now correctly intialised to zero.
References:
commit 8fcd14de18
A library should generally return an error value, rather than
printing to stderr a message. procps_loadavg() had a few things
to change:
It had a global buffer, but we don't call this function over and
over except in tload. It also did had two macros where a plain
fopen() would do the job nicely.
This removed the macro FILE_TO_BUF which was used everywhere in oldlib
but only for loadavg in newlib.
This library change will set us up to fix tload.
Make the vmstat_read_failed() return non-error for Cygwin as
it always will error because /proc/vmstat doesn't exist.
Patch from Achim of the Cygwin project.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Reference(s):
proc/uptime.c:191:9: warning: variable 'uphours' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Change the default name to cons%d
ctty can be used by other systems not just Cygwin so create a define
separate to cygwin for using the ctty function. The autoconf will need
to be updated to check for these specific systems in future.
Thanks to Achim of the Cygwin project for the patches.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
I'm not sure why you would roll your own macros for major and minor
while the standard includes have these defined. Using our versions
causes two problems:
- Some systems don't use this format for their minor/major
- If the kernel proc interface becomes a 64-bit number, like
dev_t is in the library, then our macro will need to be changed.
autoconf already had the check and as a bonus for anyone that
puts these definitions in sys/mkdev.h it handles that too.
So this is now the standard way of getting a minor/major number out of a
device id. Examining bits/sysmacros.h showed that their defines are
close to what devname.c had, except it can handle 64-bit numbers.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
When support for the 'LIBPROC_HIDE_KERNEL' environment
variable was introduced, a deficiency was present that
allowed any rejected proc_t (i.e. a kworker thread) to
preserve the strdup'd 'cmd' value. That residual value
would prevent stat2proc or status2proc from updating a
cmd field with the proper program name for some tasks.
This patch just ensures a proc_t is freshened whenever
it has been rejected due to an active PT->hide_kernel.
[ again thanks to Björn for initiating the extension ]
Reference(s):
. original hide_kernel implementation
commit 2a7ec67ac8
. original hide_kernel proposal
https://gitlab.com/procps-ng/procps/-/merge_requests/147
Signed-off-by: Jim Warner <james.warner@comcast.net>
To avoid potential user confusion, like that reflected
in the previous commit message, a short narrative will
be included in the header file as programmer comments,
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch trades some recurring per-task calculations
for calculations performed once at get, select or reap
time. It was prompted by the openSUSE dif named below.
[ my next commit will deal more thoroughly with that ]
Reference(s)
. openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif'
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the memset to zero of a 'new' meminfo_data struct
near the beginning of the meminfo_read_failed function
there's never a need to later set anything in it to 0.
[ who knows, our patch might even coax opensuse into ]
[ reevaluating that 4.0.0 'overflow' guy named below ]
Reference(s):
. overflow: 'procps-ng-4.0.0-integer-overflow.patch'
Signed-off-by: Jim Warner <james.warner@comcast.net>
On Cygwin systems use a different file and format to get the
OS version.
Thanks to procps Cygwin maintainer Achim!
Signed-off-by: Craig Small <csmall@dropbear.xyz>
As a result of the issue referenced below, we'll trade
our homegrown offset generator for an 'offsetof' macro
found in the stddef.h header file. This pleases clang.
[ and thanks to Daniel Kolesa for the report and fix ]
Reference(s):
. bug report & recommended solution
https://gitlab.com/procps-ng/procps/-/issues/235
. clang error message
proc/readproc.c:673:9: error: initializer element is not a compile-time constant
mkENT(Rss),
^~~~~~~~~~
proc/readproc.c:661:34: note: expanded from macro 'mkENT'
#define mkENT(F) { #F ":", -1, (int)((void*)&q->smap_ ## F - (void*)&q->fZERO) }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some items in the <pids> API carry a '_C' suffix which
implies such values include reaped children. So, we'll
now extend this practice to that new UTILIZATION item.
Reference(s):
. Mar, 2022 - tweak PIDS_UTILIZATION
commit 9c0e8e9429
. Feb, 2022 - added PIDS_UTILIZATION
commit c69104b2b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
When preparing the ps program for a %CUU field, it was
revealed the PIDS_UTILIZATION item may sometimes yield
a result of 'nan' or 'inf' for that ps program itself.
Apparently, it was caused by the short lived nature of
such a one-shot program. And, while this anomaly could
be handled in ps, the solution belongs in the library.
So, I reworked an item's algorithm to avoid this oops.
Signed-off-by: Jim Warner <james.warner@comcast.net>
While we really do not need the extra precision, we'll
trade that recently introduced float type for a double
for efficiency on a 64 bit platform. Additionally, the
UTILIZATION algorithm was tweaked producing less code.
The net result is four fewer machine instructions with
a reduction of 14 total bytes in that function's size.
Reference(s):
. introduced 'real' type & 'utilization' item
commit c69104b2b8
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit introduces some new capabilities available
in libproc-2 under the <PIDS> interface. Along the way
errors impacting some item values have been corrected.
The following summarizes the major changes being made.
1. The PIDS_TIME_START item was represented as seconds
since system boot but really held tics since boot. And
some programs properly divided it by Hertz to actually
yield seconds while others acted as if it already was.
So, now we have a new PIDS_TICS_BEGAN field and all of
the 'TIME' fields properly reflect seconds. With those
'TIME' fields, the type was changed to 'float/real' so
one could convert it back to tics without loss of some
centiseconds reflected in the Hertz guy (usually 100).
2. The boot_seconds was established in procps_pids_new
meaning it was fixed/unchanging. As a result, one item
(PIDS_TIME_ELAPSED) was rendered useless. So now, each
of the three retrieval functions establishes a current
boot_seconds well before the set functions are called.
3. Added a PIDS_UTILIZATION item that will provide the
CPU usage over the life of a process, as a percentage.
4. Added PIDS_TIME_ALL_C for symmetry with the similar
item called PIDS_TICS_ALL_C (which reflects raw tics).
5. That 'derived from' notation has been added to some
additional header items to reflect their true origins.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since gcc no longer warns of 'unreachable code', we'll
just deal with any such possibility ourselves I guess.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This started off with fixing the compilier warning:
proc/readproc.c: In function ‘simple_nextpid’:
proc/readproc.c:1373:38: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 58 [-Wformat-truncation=]
1373 | snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
| ^~
proc/readproc.c:1373:3: note: ‘snprintf’ output between 7 and 262 bytes into a destination of size 64
1373 | snprintf(path, PROCPATHLEN, "/proc/%s", ent->d_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We know that ent->d_name will fit under 64 bytes because we check the
name starts with a digit. The first change was simple and changed the
printf to use tgid like the task function below it.
Is everything under /proc that starts with a digit a directory with a
PID only? Today, it is but there are no guarantees.
The entire function works ok if every non-pid directory doesn't start
with a number. We don't check for strtoul() having an issue nor
if the for loop just falls off the end. The moment the kernel guys
(or some module writer) think "/proc/12mykernelval" is a neat idea this
function is in trouble. We won't get buffer overflow as we are
using snprintf at least.
This change now:
We check if strtoul() actually came across a number
Process the pid directory as a conditional branch
Treat falling off the for loop as a not-found
Signed-off-by: Craig Small <csmall@dropbear.xyz>
[ you wouldn't believe how many back-and-forths were ]
[ involved in Craig convincing me there were several ]
[ inconsistencies. i am so dense sometimes (often?). ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch was prompted by Björn Fischer's merge #147
request referenced below. It has been generalized such
that it now embraces both of those 'pids_fetch' types.
[ and thanks to Björn for initiating this extension ]
Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/147
Prototyped-by: Björn Fischer <bf@CeBiTec.Uni-Bielefeld.DE>
Signed-off-by: Jim Warner <james.warner@comcast.net>
This just updates the copyright dates in the documents
where I was already represented. Others are unchanged.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For some unknown reason all the 'info' structures were
declared between macros and function prototypes rather
than right after all the other structure declarations.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This change is really being made on behalf of the ps &
top programs. Besides, over 2 billion CPUs are plenty!
Signed-off-by: Jim Warner <james.warner@comcast.net>
Our new library's now well protected against potential
problems which arise when a multi-threaded application
opens more than one context within the same API at the
same time. However, with a single-threaded application
designed along those same lines, some problems remain.
So, to avoid potential corruption of some data (which
was classified as local 'static __thread') from those
single-threaded designs, we'll move several variables
to the info structure itself and remove the '__thread'
qualifier. Now they're protected against both designs.
[ we'll not be protected against some multi-threaded ]
[ application that shares a single context yet calls ]
[ that interface from separate threads. this is just ]
[ bad application design & no different than sharing ]
[ other modifiable global data between such threads! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
upminutes and uphours could both not get initialised in the
procps_uptime_sprint_short() function.
Error was probably introduced at the referenced commit.
References:
Coverity 240787 Uninitialized scalar variable
Coverity 240776 Uninitialized scalar variable
commit 0496b39876
Signed-off-by: Craig Small <csmall@dropbear.xyz>
This commit will place the 'file2strvec' function on a
par with the 'file2str' function if ENOMEM was raised.
Plus, just to keep coverity happy, we'll also clean up
after potential failures with the 'openproc' function.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This MR revisits a partial fix from 2018. The problem stems from incorrect
handling of unsigned 32-bit uid_ts and gid_ts as signed when values are
large - i.e. when the high bit is set. In that case, pgrep and pkill fail to
identify processes by uid. (They succeed when finding the same processes by
username.) The primary fix for this is to impliment the "FIXME" comment in
proc/readproc.h, the implementation of which allows the removal of the (int)
casts from the partial fix from 2018.
The other fixed code in this MR consists of tests in strict_atol() that
detects and errors out on overflows.
References:
Merge !146
In the commit referenced below, a '__thread' attribute
was added to numerous static variables to protect them
from concurrent access conflicts with multi-threading.
Unfortunately, that patch did not go quite far enough.
So, this commit adds a few more '__thread' qualifiers.
Reference(s):
commit 23cfb71366
Signed-off-by: Jim Warner <james.warner@comcast.net>
uptime -p would show empty output after 52 weeks of uptime. This commit
is largely the work of Ed but reformatted for newlib branch.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!141procps-ng/procps#217
Even though we we had to abandon the master branch top
multi-thread effort and even though the newlib version
of a multi-threaded top provides no real benefit, that
whole exercise was not wasted. Rather, it has revealed
some deficiencies in our library which this addresses.
If two or more threads in the same address space tried
to use procps_loadavg or procps_uptime simultaneously,
there's a chance they would experience problems due to
thread-unsafe functions our library called internally.
So, this patch switches them for thread-safe versions.
[ along the way we will also make that procps_uptime ]
[ initialization of his 'up' & 'idle' variables mean ]
[ something by delaying the -ERANGE return a little. ]
Reference(s):
https://www.freelists.org/post/procps/a-few-more-patches,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Even though we we had to abandon the master branch top
multi-thread effort and even though the newlib version
of a multi-threaded top provides no real benefit, that
whole exercise was not wasted. Rather, it has revealed
some deficiencies in our library which this addresses.
If two or more threads in the same address space tried
to access the same api simultaneously, there is a good
chance some function-local static variables will yield
some of those renowned unpredictable results. So, this
patch protects them with the '__thread' storage class.
Reference(s):
https://www.freelists.org/post/procps/a-few-more-patches,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ever since 2003, the 'listed_nextpid' routine has been
misrepresenting its duties. Far from finding processes
in a list given to openproc, it just inserted the next
pid in that list into the passed proc_t as BOTH a tgid
and tid. There was no attempt to validate such values.
The net result is that tid & tgid were valid only with
a thread group leader. When called with a pid for some
sibling thread, the resulting tgid would be incorrect.
With this commit, our little function will now attempt
to validate both the tid and tgid. If this should fail
then the fallback position will be the same as what we
inherited. So we're no worse off & likely much better.
[ note that calling the function with a thread's pid ]
[ likely stems from 2011 when a 'readeither' routine ]
[ was added which dealt with both tasks and threads! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the patch shown below, two lines involving the flag
PROC_UID were uncommented (enabled). However given the
construct of the readeither function, it is impossible
for the simple_readtask guy to be called when its TGID
leader has already been ignored. So, let's disable it.
[ it's only now true that the lines serve no purpose ]
[ after the commit shown below tweaked readeither to ]
[ access the base directory of the tgid leader. but, ]
[ before that, the 2 lines should have been enabled! ]
Reference(s):
. two lines uncommented
commit af34cc964a
. tweaked readeither
commit a375262609
Signed-off-by: Jim Warner <james.warner@comcast.net>
The patch referenced below corrected some flaws in the
procps_pids_select implementation. But, there remained
one flaw which this commit will now hopefully address.
Rather than assume callers wished to select only tasks
and not threads meant a command like 'top -H -p 10329'
works differently under newlib than release 3.3.17. It
fails to honor the '-H' (threads) switch under newlib.
So, to fix that oops, we'll allow that select function
to get threads or tasks depending on its 'which' parm.
Reference(s):
. Oct 2015, some flaws corrected
commit bc616b3615
Signed-off-by: Jim Warner <james.warner@comcast.net>
With that recent addition of the autogroup provisions,
it became apparent that '/proc/<pid>/task' information
is sometimes incomplete. In fact, there's no autogroup
file at all in any '/proc/<pid>/task/<pid>' directory!
As a result, when the top -H mode was invoked, all the
processes showed a -1 for AGID, even the group leader.
So, this commit will ensure that for every TGID leader
its basic '/proc/<pid>' directory will always be used.
The 'task' subdirectory is now only used for siblings.
[ and it's time that readeither prologue was updated ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the link referenced below there's an explanation of
the linux autogroup feature which has been around ever
since linux-2.6.38. With that explanation there's also
surprising (maybe shocking) revelations about the nice
and renice commands if CONFIG_SCHED_AUTOGROUP was set.
When autogroups are active, such programs are rendered
mostly useless because the nice value will only affect
scheduling priority relative to other processes in the
same autogroup. In order to accomplish what we thought
of as renice, that nice value in /proc/<pid>/autogroup
must be changed. Altering any single member of a group
will also affect every other member of that autogroup.
So, this commit will set the stage for users of newlib
to display autogroup identifiers plus their associated
nice values (now that their importance is understood).
Reference(s):
https://github.com/nlburgin/reallynice
Signed-off-by: Jim Warner <james.warner@comcast.net>
