]> granicus.if.org Git - procps-ng/commit
library: correct a flawed approach for PROCPS_FILL_UID
authorJim Warner <james.warner@comcast.net>
Thu, 8 Oct 2015 05:00:00 +0000 (00:00 -0500)
committerCraig Small <csmall@enc.com.au>
Fri, 9 Oct 2015 10:35:04 +0000 (21:35 +1100)
commitbc616b361596bc3008800de839b88446508cfdd0
treec80dcb42c2e3225de9af96ead011938194c141cc
parent99a657b36545f86a08d818720142b3a0a69fb11f
library: correct a flawed approach for PROCPS_FILL_UID

Gosh, just because nobody uses some newlib provision I
guess, since it is being offered, it ought to actually
be tested at some point. Well, that point just arrived
and guess what? A surprise: some bugs were discovered.

The procps_pids_select function established a for loop
wherein readproc is called until the passed 'maxthese'
limit. Unfortunately this was incorrect for 2 reasons:

1. For PROCPS_FILL_PID results are limited by what the
oldlib finds, having established the pid list at open.
Total found already cannot exceed a passed 'maxthese';

2. With PROCPS_FILL_UID, returned results could exceed
a 'maxthese' thus making the for loop incorrect again.

[ plus yours truly neglected to forward the required ]
[ UIDs total to our old library, another oops biggie ]

In summary: the loop should have been forever, exiting
only when all those identified procs had been located.

So, while addressing those bugs, I've consolidated all
the retrieval code (initialize, iterate, summarize) in
a single helper function which will now serve both the
procps_pids_reap and select functions. And as a result
those guys were reduced to quite trivial housekeeping.

This patch, hopefully, completes the normalization for
reap/select (fill), which began with references shown.

Reference(s):
commit 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2
commit 747dfc5987e6e91ea3a8575de307e2892790c598

Signed-off-by: Jim Warner <james.warner@comcast.net>
proc/pids.c