cURL / Mailing Lists / curl-library / Single Mail


gethostbyname_r and TRY_AGAIN (was Re: Feature freeze for 7.18.0)

From: Daniel Stenberg <>
Date: Tue, 15 Jan 2008 11:42:55 +0100 (CET)

On Mon, 14 Jan 2008, Maxim Perenesenko wrote:

(since Dan F "took" the other issue, I'll reply to this with a new subject)

> There is one more not critical bug I found and fixed in 7.16.2 while working
> on my project. And this bug is not fixed in the latest sources.
> Shortly: hostip4.c#117 function Curl_getaddrinfo TRY_AGAIN is not handled at
> call to gethostbyname_r.
> I guess this bug affects only libcurl without c-ares support.
> I have named daemon configured as caching nameserver to resolve hostnames.
> Target host name is successfully resolved through f.e. dig. gethostbyname_r
> on fedora 3,4,5,6 (tested) has about 10 sec timeout before returning
> TRY_AGAIN error. When I have hundreds of threads working with various hosts,
> it seems the named daemon sometimes needs more than 10 seconds to resolve
> hosts. And I got the error and was forced to restart curl session to try
> again. It was quite critical for me at that time.
> I fixed it very straightforward, like the following:
> maxtries = 3;
> while( need_syscall && tries < maxtries )
> {
> need_syscall = false;
> ++tries;
> gethostbyname_r(..., &h_errnop)
> if( h_errnop == TRY_AGAIN )
> need_syscall = true;
> }
> So... I can send the patch with this hotfix, or maybe discuss it, or
> we may forget about it :)

Hm, yeah I guess it makes sense to do some retries on that error. At least
while the timeout time hasn't been reached since libcurl has no proper way to
return this as a "transient" error.

Can you please provide a patch for us to review? I take it it will need to
only be for the glibc-style gethostbyname_r() as we can't really be sure about
how all the other alternatives work...

  Commercial curl and libcurl Technical Support:
Received on 2008-01-15