The symptom:
* Users (usually, but not always) on 2-Wire routers and the Comcast service
and a wired connection to their router would find that the second and
subsequent DNS lookups from fresh processes using c-ares to resolve the same
address would cause the process to never see a reply (it keeps polling for
around 1m15s before giving up).
The repro:
* On such a machine (and yeah, it took us a lot of QA to find the systems
that reproduce such a specific problem!), do 'ahost www.secondlife.com',
then do it again. The first process's lookup will work, subsequent lookups
will time-out and fail.
The cause:
* init_id_key() was calling randomize_key() *before* it initialized
key->state, meaning that the randomness generated by randomize_key() is
immediately overwritten with deterministic values. (/dev/urandom was also
being read incorrectly in the c-ares version we were using, but this was
fixed in a later version.)
* This makes the stream of generated query-IDs from any new c-ares process
be an identical and predictable sequence of IDs.
* This makes the 2-Wire's default built-in DNS server detect these queries
as probable-duplicates and (erroneously) not respond at all.
Prior versions of autoconf defined _ALL_SOURCE if _AIX was defined. But,
autoconf 2.62 version of AC_AIX defines _ALL_SOURCE along with other four
preprocessor symbols no matter if the system is AIX or not. To keep the
traditional behaviour, as well as an uniform one, across autoconf versions
AC_AIX is replaced with our own internal macro.
This quadigraph used before a C preprocessor 'define' directive could
be fooling M4, when processing this file, and make it think that the
line contains a pure M4 'define' macro.
in top Makefile.am triggered a problem that prevented aclocal from running
successfully on SunOS 5.10 with GNU m4 1.4.5 and GNU Autoconf 2.61
A tarball which reproduces mentioned problem is the one dated July-28-2008
http://cool.haxx.se/curl-daily/curl-7.19.0-20080728.tar.gz
We actually don't need all the bells and whistles that the above mechanism
provides. We only need to include our m4/reentrant.m4 file in acinclude.m4
so here we go with this simpler mechanism.
but it breaks aclocal execution on some systems, with the following error:
Can't locate object method "rel2abs" via package "File::Spec" at /usr/local/bin/aclocal line 256.
needed, and being able to define it if appropriate for further configure tests
as well as for the generated config file.
Introduced reentrant.m4 intended for our reentrant related autotools/m4 macros.
function recvfrom as a result of the info additionally logged when running on a
Solaris system.
The compiler error showed that the prototype being used on Solaris was the one
declared in line 427 of "/usr/include/sys/socket.h" as:
function(int,
pointer to void,
unsigned int,
int,
pointer to struct sockaddr,
pointer to void) returning int
finds out its return type and the types of its arguments. Added definitions
for non-configure systems config files, and introduced macro sreadfrom which
will be used on udp sockets as a recvfrom() wrapper.
the target host has only A records, it automatically falls back to an
AF_INET lookup and gives you the A results. However, if the target host has
a CNAME record, this behaviour is defeated since the original query does
return some data even though ares_parse_aaa_reply() doesn't consider it
relevant. Here's a small patch to make it behave the same with and without
the CNAME.
not posix or anything and thus c-ares failed to build on hurd (and possibly
elsewhere). The define was also somewhat artificially used in the windows
port. Now, I instead rewrote the use of gethostbyname to enlarge the host
name buffer in case of need and totally avoid the use of the MAXHOSTNAMELEN
define. I thus also removed the defien from the namser.h file where it was
once added for the windows build.
I also fixed init_by_defaults() function to not leak memory in case if
error.
some systems" (http://curl.haxx.se/bug/view.cgi?id=1999181). The problem was
that the configure script did not use the _POSIX_MONOTONIC_CLOCK feature test
macro when checking monotonic clock availability. This is now fixed and the
monotonic clock will not be used unless the feature test macro is defined
with a value greater than zero indicating always supported.
enough at detecting compilation errors or at least it has been properly
configured to do so. Configuration heavily depends on this capability, so
if this compiler sanity check fails the configuration process will now fail.
