Bug 137202

Description of problem:

The getXXXent functions blow up after recursing.  Google reveals
numerous cases of people hit with "panic: realloc".  WebMin blows up
on production systems (but not test systems!) because of this bug.

At end of data, glibc's getgrent_r returns ENOENT but does not set
errno.  Arguably this is a bug in glibc:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137199

However, PERL should be more resilient.  The getXXXent functions
should clear errno before starting.  (Note: this also handles the
recursion case as Perl_reentrant_retry calls them again after doubling
the buffer size.)

Version-Release number of selected component (if applicable):

Reproduced in perl-5.8.3-18 and perl-5.8.5-4.
(Was not present in perl-5.8.0-88.3.)

How reproducible:

Always.

Steps to Reproduce:

1. Ensure that you have a group containing several hundred users in
/etc/group.  The group and the users do not need to be "real".  It's
thirty seconds work to create such a group in emacs.  Our system blows
up unless we reduce the number of users below 360 - so if you create a
test case with 2^10 usernames you'll succeed.
2. Run the attached test program.
  
Actual results:

At the end of /etc/group, you get a panic: realloc.

Expected results:

No panic.

Additional info:

At the end of /etc/group, glibc's getgrent_r returns ENOENT but errno
is unchanged.  If there has previously been a recursion, errno
contains ERANGE.  Perl_reentrant_retry sees the ERANGE and retries,
continuously doubling the buffer size until it explodes.