Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <47FDE7DB.6720.00AC.0@novell.com>
Date: Thu, 10 Apr 2008 10:11:46 -0600
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>
Subject: Re: svn commit: r646582 -
	/httpd/httpd/trunk/modules/ldap/util_ldap.c
References: <20080409224936.BA4F21A9832@eris.apache.org>
 <47FDAFE4.4070806@apache.org>
In-Reply-To: <47FDAFE4.4070806@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

>>> On 4/10/2008 at 12:12 AM, in message <47FDAFE4.4070806@apache.org>,
Ruediger
Pluem <rpluem@apache.org> wrote:
> On 10.04.2008 00:49, bnicholes@apache.org wrote:
>> Author: bnicholes Date: Wed Apr  9 15:49:31 2008 New Revision:
646582
>> 
>> URL: http://svn.apache.org/viewvc?rev=646582&view=rev Log: Move the
>> initialization of rebind to the post_config handler so that it is
done 
> during
>> the actual module load stage rather than the preload stage.  If done
during
>> the preload stage, the pool passed into the initialization function
will be
>> cleared and all allocations will be freed.
> 
> But isn't it the pconf pool in both cases? Currently I cannot follow
this 
> argument. Mind to explain in more detail?
> 
> Regards
> 
> R�diger

What is happening is that when httpd is invoked, the first thing it
does is preload all of the modules to make sure that everything works. 
The preload of the modules also calls the util_ldap_create_config()
which subsequently calls apr_ldap_rebind_init().  In
apr_ldap_rebind_init() some allocations are done.  Actually a thread
mutex is created against the pool that was passed in.  In addition, the
clean up of the mutex was tied to the pool and the rebind init function
also assigned to a global static variable, the mutex handle.  Then when
the preload stage is complete, it clears the memory pool which also
causes the mutex to be destroy.  However the mutex handle, which is now
bogus, is still assigned to the global static variable.  Finally the
real module loading stage occurs and util_ldap_create_config() and
apr_ldap_rebind_init() are called again.  Only this time the
apr_ldap_rebind_init() sees that the mutex global static variable is no
longer NULL so it doesn't bother to recreate the mutex leaving a bogus
value in the static variable.  When an ldap authentication occurs later
and tries to use the bogus mutex handle, at least on NetWare, the code
segfaults. 

The change was simply moving the init of the rebind functionality to a
location in the code where everything else is initialized and is also
protected so that the initialization only happens during the real module
load stage rather than the preload stage.

Brad