Sander Striker wrote:
I tagged the trees today, as STRIKER_2_0_48_PRE1 and STRIKER_2_1_0_PRE1 respectively. I'll try and get some tarballs up for testing, but for now, please test the tag.
with recent apr resolver changes, Apache on AIX has picked up the old assert failure that solaris-8-with-no-patches used to have... investigating further...
(I think this is a different assert() failure. I don't think the call presently failing used to go to the resolver, and now it does.)
It looks like AIX's getaddrinfo() always fails if service is "0", which should be easy to work around in APR (and a good excuse to bother the AIX resolver folks as the same call seems to work on some other platforms, but meanwhile I have questions about the call in Apache that fails. Specifically, it is possible that Apache should change because of a semantics change in apr_sockaddr_info_get()?
The code that pukes in server/config.c is
/* NOT virtual host; don't match any real network interface */
rv = apr_sockaddr_info_get(&s->addrs->host_addr,
NULL, APR_INET, 0, 0, p);
ap_assert(rv == APR_SUCCESS); /* otherwise: bug or no storage */In prior APR, a call with hostname=NULL meant "just build me a sockaddr" but now it means we call getaddrinfo() with AI_PASSIVE flag set.
Conceptually, specifying AI_PASSIVE results in a list of socket addrs that the app should bind to. "Just build me an IPv4 sockaddr" is different than that. But I don't know where empirically they will differ given that the family is hard-coded in this call.
Does anybody have a firmer grasp on the semantic differences between old APR and new APR for hostname=NULL/family=APR_INET? If so, then perhaps server/config.c needs to be changed to just create an all-zeros socket address manually, without involving the resolver. (Or we ask ourselves if the APR semantics should have changed.)
