This one time, at band camp, Guido Guenther said: > Hi Stephen, > On Sat, May 26, 2007 at 11:51:33PM +0000, Stephen Gran wrote: > > Which looks really good, until you spot the subtle flaw: the goto does > > not actually retry the group that returned NSS_STATUS_TRYAGAIN, it tries > > to grab the next group off the list. getgrent always returns the next > > group in the list each time it's called - it doesn't notice that the > > this is confusing. Running with this patch for testing:
I've updated your patch to this:
@@ -168,13 +168,16 @@
tryagain:
do {
status = vtable->getent((void *)&result, buffer, buflen, &errnop);
+ printf("gid_t: %d starting\n", result.gr.gr_gid);
if (status != NSS_STATUS_SUCCESS) {
break;
}
+ printf("gid_t: %d done\n", result.gr.gr_gid);
status = callback(handle, (void *)&result, private);
} while (status == NSS_STATUS_SUCCESS);
if (status == NSS_STATUS_TRYAGAIN) {
+ printf("Enlarging buffer from %d to %d\n", buflen, buflen*2);
buflen *= 2;
buffer = realloc(buffer, buflen);
if (buffer == NULL) {
And this is the output:
gid_t: 10110 starting
gid_t: 10110 done
gid_t: 10800 starting
Enlarging buffer from 496 to 992
gid_t: 11197 starting
gid_t: 11197 done
Note that gid 10800 (the giant group) never shows done.
> Note that the group with gid 10000 is the only group that needs the
> buffer enlarged (I've been running with a reduced buffer size of 128
> bytes for testing), this is current unstable with glibc 2.5). A similar
> test on sarge (glibc 2.3.2) fetching several thousand users from ldap
> works fine too and for completeness I checked glibc and getXXbyYY_r.c in
> glibc 2.3.5 suggests something different:
>
> /* The status is NSS_STATUS_TRYAGAIN and errno is ERANGE the
> provided buffer is too small. In this case we should give
> the user the possibility to enlarge the buffer and we should
> not simply go on with the next service (even if the TRYAGAIN
> action tells us so). */
I saw that, and what it says to me is that the only way to do this is to
rewind to the top of the loop and try again with a larger buffer.
Currently, the buffer is being resized for all subsequent getent calls,
but not for the failed one.
> Might this be a bug affecting etch only?
I don't think so, based on the above output.
Take care,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [EMAIL PROTECTED] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
signature.asc
Description: Digital signature
