Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47E18EF5.1050704@rowe-clan.net>
Date: Wed, 19 Mar 2008 17:08:53 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: PR44641: Does patch make sense
References: <47E17F2F.4080508@apache.org> <20080319212220.3814b5a0@grimnir>
 <47E189A3.4010706@apache.org>
In-Reply-To: <47E189A3.4010706@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ruediger Pluem wrote:
> 
> 
> On 03/19/2008 10:22 PM, Nick Kew wrote:
>> On Wed, 19 Mar 2008 22:01:35 +0100
>> Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>> Does the following patch for PR44641 attached by the reporter makes
>>> sense?
>>>
>>> https://issues.apache.org/bugzilla/attachment.cgi?id=21691
>>>
>>> I am a little bit worried that we could use the wrong pool in
>>> register_hooks. So some additional eyes please.
>>
>> Looks to me like he's right about the bug, and you're right
> 
> No doubt about this.
> 
>> about the pool.  Though the pool usage is pretty negligible,
>> so we could just turn a blind eye to it.
>>
>> If we want to be fussy, we could create a subpool and destroy
>> it in post_config.
>>
> 
> I am *not* worried about some sort of memory leak with the pool used
> by register_hooks. It is the contrary: I am not sure if the register_hooks
> pools gets destroyed / cleared too *early* or in between so that we are 
> pointing
> to invalid memory. So please some eyes on this aspect.

What happens is that a module must register itself during config, and
remove itself from the hash during post-config.  Hopefully during the
re-config phase it replaces it's own hash registration.

If this doesn't happen and the module is removed from the list during a
graceful restart, there will still be a hash entry into it.

It's possible to do a pconf teardown resetting the hash, but if we reset
while modules are unregistering themselves, we are back to the original
fault.