Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3C9755AE.7060009@xbc.nu>
Date: Tue, 19 Mar 2002 16:13:50 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.9) Gecko/20020311
MIME-Version: 1.0
To: Sander Striker <striker@apache.org>
CC: APR Development List <dev@apr.apache.org>,
        Bill Stoddard
 <bill@wstoddard.com>
Subject: Re: Win32 segfault in allocator code
References: <JLEGKKNELMHCJPNMOKHOOEIHFIAA.striker@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sander Striker wrote:

>>From: Bill Stoddard [mailto:bill@wstoddard.com]
>>Sent: 19 March 2002 05:43
>>
>
>>>I'm pretty sure I have identified the problem on Windows.  The blow up happens when we
>>>are trying to obtain a mutex that has been freed. This happens on the very last pool to be
>>>cleaned up (the "global_pool"). In apr_pool_destroy, we call the pool cleanups (one of
>>>which is for the mutex in the allocator) then call apr_allocator_free() which proceeds
>>>to attempt to acquire the mutex that was just freed.
>>>
>
>Oh, duh!  Why didn't I think of that?
>Thanks for tracking this down Bill.
>
>
>>This hack of a patch eliminates the seg fault.  I am not so familier with the pool code and
>>am not inclined to dig into it right now.  Perhaps the check to NULL out the mutex should
>>be
>>
>>if (apr_allocator_get_owner(allocator) == pool) {
>>
>>???
>>
>
>Yes, that is the correct spot.  I've committed a patch similar to yours.
>

That patch doesn't solve the problem. apr_terminate still crashes in the 
pool cleanup.

-- 
Brane Čibej   <brane@xbc.nu>   http://www.xbc.nu/brane/