mirror of
https://github.com/curl/curl.git
synced 2024-11-21 01:16:58 +08:00
EAGAIN on older (correct) glibc versions indicate a problem and not the need
for a bigger buffer and this is indeed badness for us. Making this work on both old and new glibc versions require an ugly loop that in its worse form cause 45 bad loops when using the correct glibc and a non-resolving host name... :-/ We want a better fix. Badly.
This commit is contained in:
parent
96d84150e1
commit
e879e26a5b
20
lib/hostip.c
20
lib/hostip.c
@ -631,16 +631,28 @@ static Curl_addrinfo *my_getaddrinfo(struct SessionHandle *data,
|
||||
&h, /* DIFFERENCE */
|
||||
&h_errnop);
|
||||
/* Redhat 8, using glibc 2.2.93 changed the behavior. Now all of a
|
||||
sudden this function seems to be setting EAGAIN if the given buffer
|
||||
size is too small. Previous versions are known to return ERANGE for
|
||||
the same. */
|
||||
sudden this function returns EAGAIN if the given buffer size is too
|
||||
small. Previous versions are known to return ERANGE for the same
|
||||
problem.
|
||||
|
||||
This wouldn't be such a big problem if older versions wouldn't
|
||||
sometimes return EAGAIN on a common failure case. Alas, we can't
|
||||
assume that EAGAIN *or* ERANGE means ERANGE for any given version of
|
||||
glibc.
|
||||
|
||||
For now, we do that and thus we may call the function repeatedly and
|
||||
fail for older glibc versions that return EAGAIN, until we run out
|
||||
of buffer size (step_size grows beyond CURL_NAMELOOKUP_SIZE).
|
||||
|
||||
If anyone has a better fix, please tell us!
|
||||
*/
|
||||
|
||||
if((ERANGE == res) || (EAGAIN == res)) {
|
||||
step_size+=200;
|
||||
continue;
|
||||
}
|
||||
break;
|
||||
} while(1);
|
||||
} while(step_size <= CURL_NAMELOOKUP_SIZE);
|
||||
|
||||
if(!h) /* failure */
|
||||
res=1;
|
||||
|
Loading…
Reference in New Issue
Block a user