Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Sender: trawick@rdu163-40-092.nc.rr.com
To: dev@httpd.apache.org
Cc: jfrederic.clere@fujitsu-siemens.com
Subject: Re: Solaris8 Problem with native compiler
References: <3C601E13.EAD437B9@fujitsu-siemens.com>
From: Jeff Trawick <trawick@attglobal.net>
Date: 05 Feb 2002 13:48:48 -0500
In-Reply-To: <3C601E13.EAD437B9@fujitsu-siemens.com>
Message-ID: <m3adunbw8f.fsf@rdu163-40-092.nc.rr.com>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

jean-frederic clere <jfrederic.clere@fujitsu-siemens.com> 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 | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...