Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 24941 invoked by uid 500); 19 Jul 2003 15:30:38 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 24915 invoked from network); 19 Jul 2003 15:30:37 -0000 Message-ID: <3F1963F0.2010302@wstoddard.com> Date: Sat, 19 Jul 2003 11:29:52 -0400 From: Bill Stoddard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brad Nicholes CC: jwoolley@virginia.edu, dev@apr.apache.org Subject: Re: Creating an allocator with no mutex... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Great catch guys. This probably saved Jeff, Greg and I some major league headaches in the future :-) Bill Brad Nicholes wrote: > I think we just discovered what the real source of the problem is. It > appears that apr_pool_create_ex() is trying to extract the mutex from > the wrong allocator when an allocator is specified. When it tries to > get the mutex it uses the parent allocator if one was not passed in. If > an allocator was passed in then it uses that one instead which is wrong. > The mutex from the allocator that was passed in does not protect the > parent but the code still manipulates it anyway. This means that two or > more threads could overwrite parent->child simply because the wrong > mutex was locked or no mutex was locked at all (in our case). The call > to apr_allocator_mutex_get() should use "parent->allocator" not > "allocator". If you look at apr_pool_destroy() it is doing it > correctly. Otherwise this code is not thread safe. > > Brad >