Arch Linux

 FS#22151 

does it still segfaults with c-ares compiled?

is there a test case to reproduce the seg fault ?

I can't recreate the segfaults any more (they were probably on my end), but keep in mind that c-ares does not provide a full reimplementation of getaddrinfo and gethostbyname, e.g. they will not use /etc/hosts for lookups. I think this is fairly detrimental.

Are you sure about that. I can see in the code the presence of some routine that do read /et/hosts. I am sorry I don't have much time to test, but apparently some of the required code is here.

I must have been reading old and outdated posts from Daniel Stenberg then. My experience with c-ares is still somewhat flakey after extensive testing. I link against it for a few of my projects and I'm not convinced usage of c-ares is really all that big of a deal unless you're creating and recreating numerous short lived connections. What's the argument _for_ enabling c-ares other than the usual plea of 'it does asynchronous lookups'? I have to believe that many other distros haven't just "forgotten" to enable support for this. At a glance, Canonical and RedHat have yet to enable support for this. Furthermore, the maintainer of the Fedora package (Kamil Dudka) is a sanctioned curl maintainer.

edit/update: I've emailed Kamil, asking why Fedora chooses not to do this. also, add debian to the list of packagers who don't link it [1][2].

[1] http://curl.haxx.se/mail/lib-2008-11/0238.html
[2] http://git.debian.org/?p=collab-maint/curl.git;a=blob;f=debian/rules;h=fd31a2718973594631480f8c64f30ed25e891798;hb=HEAD (note the comment near the ./configure step)

I was using Debian before, and advocated with the maintainer at that time to do the build with c-ares. We did try, but sadly we did have issue with IPv6 support. I worked since then on c-ares and they should now support IPv6 correctly. If not that's a bug that should be fixed upstream.

As for what is the purpose of enabling the build of curl with cares, non-blocking application when network isn't working well is more than an issue. For example it does affect window manager that do use libcurl for some network gadget, making the whole experience bad or broken in some case.

Below is reply I received from Kamil and Daniel Stenberg (curl and c-ares lead dev). Even with the ipv6 issues resolved in curl, it's my opinion that c-ares isn't something that we would want enabled distro-wide. Building with curl's own --enable-threaded-resolver seems to be a nice workaround. My mild testing thus far hasn't coughed up any problems with it yet.


Hi Dave,

[I've CC'd Daniel Stenberg as curl's and c-ares' upstream maintainer]

we tried to switch (lib)curl to c-ares in Fedora a year ago. Unfortunately,
it has not been much successful. Our distribution was simply not ready for
such a change and it trigerred an avalanche of bug reports:

https://bugzilla.redhat.com/show_bug.cgi?id=548269
https://bugzilla.redhat.com/show_bug.cgi?id=548396
https://bugzilla.redhat.com/show_bug.cgi?id=549088
https://bugzilla.redhat.com/show_bug.cgi?id=554305
https://bugzilla.redhat.com/show_bug.cgi?id=562209

To sum it up, there were two major problems:

1) c-ares could not return both A and AAAA records for one host such that
curl could fall back to IPv4 if IPv6 connect failed. Not sure if that
has been improved since then.

2) c-ares completely ignores the plug-ins of glibc's NSS (mDNS, NIS, etc.).
Unfortunately, this (even in principal) can't be fixed. The functionality
of that plug-ins could be probably re-implemented in c-ares, but such an
approach does not scale well for new plug-ins.

Luckily, the support for threaded DNS resolver has been finally made upstream,
so we replaced c-ares with that in Fedora's curl. I am glad to confirm that
absolutely no bug reports related to that have reached or bugzilla since
then.

Kamil

-------------------------------------------------------

Subject: Re: packaging libcurl with c-ares
Date: Monday 07 February 2011
From: Daniel Stenberg <daniel@haxx.se>
To: Kamil Dudka <kdudka@redhat.com>

On Mon, 7 Feb 2011, Kamil Dudka wrote:

Hi guys,

I have only some little details to add to this excellent summary:

> 1) c-ares could not return both A and AAAA records for one host such that
> curl could fall back to IPv4 if IPv6 connect failed. Not sure if that
> has been improved since then.

c-ares has not been improved in this area, but libcurl has! In the current git
version, to be shipped in the next release, it will ask c-ares to return both
AAAA and A entries if built for IPv6 and this fixes most (if not all) the
previous IPv6 problems with (lib)curl built to use c-ares.

> 2) c-ares completely ignores the plug-ins of glibc's NSS (mDNS, NIS, etc.).
> Unfortunately, this (even in principal) can't be fixed. The functionality
> of that plug-ins could be probably re-implemented in c-ares, but such an
> approach does not scale well for new plug-ins.

Right. For those use-cases there's no fix in sight with the c-ares approach...

--

/ daniel.haxx.se

Still have yet to experience any show-stopper issues with --enable-threaded-resolver, including with today's 7.21.4 release. With a new build of curl in the queue, could we perhaps get a resolution on this one way or another?