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:
diff --git a/updatedb.c b/updatedb.c
index fb6f8cf..fc4e7d4 100644
--- a/updatedb.c
+++ b/updatedb.c
@@ -171,10 +171,12 @@ tryagain:
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) {
the (truncated) output is:
...
gid_t: 127 done
gid_t: 107 done
gid_t: 128 done
gid_t: 129 done
gid_t: 112 done
Enlarging buffer from 128 to 256
Enlarging buffer from 256 to 512
gid_t: 10000 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). */
> Versions of packages nss-updatedb depends on:
> ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
Might this be a bug affecting etch only?
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
