jean-frederic clere <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have some problems with the httpd-2.0 (from CVS).
> Whe compiled with Sun compiler it hangs at startup:
> +++
> > $c
(some internal library calls omitted)
> libsocket.so.1`getaddrinfo+0x524(ff31ac0c, 93c08, 1e62, ffbefa1c, ff31a000,
> ffbef980)
> libapr.so.0`apr_sockaddr_info_get+0x14c(d7cc4, 93c08, 0, 1e62, 0, 95930)
> ap_mpm_pod_open+0xd8(95930, 8a66c, 49, 1, ff3e0000, ff370330)
> prefork_open_logs+0xb0(95930, bd9f8, bfa00, 975e0, bfa00, 0)
> ap_run_open_logs+0x98(95930, bd9f8, bfa00, 975e0, 0, 0)
> main+0x864(1, ffbefc9c, ffbefca4, 87800, 0, 0)
> _start+0xb8(0, 0, 0, 0, 0, 0)
At the moment I'm not sure why that apr_sockaddr_info_get() is
there. It looks a little mysterious to me, but I haven't looked into
it.
As for why getaddrinfo() is hanging... It shouldn't do that :) Are
there some resolver timeouts you can set on the system? There isn't a
WAIT_FOREVER flag to getaddrinfo(), so that is a Sun question :(
Back to reality, where we need to deal with this:
1) If you want to experiment with what might work around the
problem... You could replace APR_UNSPEC in ap_mpm_pod_check() with
AF_INET and see if that avoids the apparent WAIT_FOREVER path in the
resolver.
2) Maybe Jeff needs to learn about that particular
apr_sockaddr_info_get() call to see if it could be changed. For
now, I dunno.
--/--
For better or worse, some months back APR decoupled the choice of
using getaddrinfo() from the choice of enabling IPv6 support, so
--disable-ipv6 doesn't switch us to the older, better-understood
resolver logic.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
