Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 63212 invoked by uid 500); 9 Aug 2001 19:23:45 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 63174 invoked from network); 9 Aug 2001 19:23:45 -0000 X-Authentication-Warning: rdu26-58-158.nc.rr.com: trawick set sender to trawick@attglobal.net using -f Sender: trawick@rdu26-58-158.nc.rr.com To: new-httpd@apache.org Cc: shbhatna@cisco.com Subject: Re: Spurious return from select() References: <3B6ECBF7.61F38773@cisco.com> <3B714E46.416F700A@cisco.com> From: Jeff Trawick Date: 09 Aug 2001 15:12:23 -0400 In-Reply-To: <3B714E46.416F700A@cisco.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 348 Shail Bhatnagar writes: > Jeff, Thanks for your response. I am > using the standard child_main() loop > in which select() is protected by the > mutex. The only difference is that the > parent is bound to a well known udp > port and so all children are monitoring > this well known port. Despite this mutex, > I see this behavior fairly consistently. > The frequency is more on solaris than on linux. you are calling recvfrom() while still holding the accept mutex, right? no other idea... > The crash that I saw was in apr_pool_alloc_init(). > apr_lock_create() failed, although there were > not permissions problems and then apr_lock_destroy() > crashed while accessing a NULL pointer. > > The relevant code fragment in apr_pool_alloc_init() is : > #if APR_HAS_THREADS > status = apr_lock_create(&alloc_mutex, APR_MUTEX, APR_INTRAPROCESS, > NULL, globalp); > if (status != APR_SUCCESS) { > apr_lock_destroy(alloc_mutex); > return status; > } well, clearly apr_lock_destroy() shouldn't be called if the mutex wasn't successfully created... I'll commit a fix in a jiffy the question most interesting to me is why this apr_lock_create() failing for you and for noone else... (I guess it just happened once?) if you can manage to recreate, please run truss/strace on the program so we can see what syscall is failing, and with what errno -- Jeff Trawick | trawick@attglobal.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...