Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <2B91D9737CCB0D498BAC46BED45A7BD7185B56@xsun02.ptp.hp.com>
From: "CHOU,TAIR-SHIAN (HP-Cupertino,ex1)" <tair-shian_chou@am.exch.hp.com>
To: "'dev@httpd.apache.org'" <dev@httpd.apache.org>
Subject: RE: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Date: Mon, 10 Nov 2003 10:35:24 -0800
MIME-Version: 1.0
Content-Type: text/plain

Hi Matthieu,

> SHM is now initialised in post_config hook, so apr_shm_create and 
> apr_rmm_init are just called one time when apache is startup.
> Then, all the lock are now using the module structure to lock 
> data, and 
> no more a global variable.
> 

Is this lock global to all processes? If all processes still share the same
cache, it needs to be a system-wide lock.

The use of the lock is 

 LDAP_CACHE_LOCK_CREATE(st->pool);
 LDAP_CACHE_WRLOCK();
 LDAP_CACHE_UNLOCK();

This may cause a race condition in the creation of the lock in worker mpm,
shouldn't the lock be created before used by any threads?

Thanks,

Chou 


> CHOU,TAIR-SHIAN (HP-Cupertino,ex1) wrote:
> 
> >Hi Matthieu,
> >
> >We are also seeing the same problem on HP-UX running 2.0.47 
> with mod_ldap
> >enabled. We have done some analysis and we think we might 
> have found the
> >problem.
> >
> >The cache memory is shared by all processes(one process 
> creates it and other
> >processes just attaches to it). After a process attached to 
> the shared
> >memory, it calls apr_rmm_init to create a rmm handler to the 
> shared memory.
> >The following code in apr_rmm_init looks suspicious:
> > 
> >
> >    (*rmm)->base->abssize = size;
> >    (*rmm)->base->firstused = 0;
> >    (*rmm)->base->firstfree = sizeof(rmm_hdr_block_t);
> >
> >base points to the header block of the shared memory which 
> contains abssize,
> >firstused and firstfree for managing the shared memory. 
> These code will
> >reset the size, the free and allocated trees in the shared 
> memory. Imagine
> >what may happen if the memory was already allocated and the 
> new process
> >re-initializes these values again. The previous contents 
> will be lost.
> >
> >The header block should be initialized only once and access 
> to the header
> >block needs to be synchronized among all processes. Right 
> now, it is only
> >synchronized using process specific rwlock. They should be 
> replaced by
> >system-wide rwlock.
> >
> >Chou
> >  
> >
> >>-----Original Message-----
> >>From: Matthieu Estrade [mailto:apache@moresecurity.org]
> >>Sent: Monday, November 03, 2003 12:37 AM
> >>To: dev@httpd.apache.org
> >>Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
> >>
> >>
> >>Hi Albert,
> >>
> >>Could you try this little patch posted on bugzilla: 
> >>http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8185
> >>It works under linux but still not work with solaris... i 
> >>never tested 
> >>it on FreeBSD.
> >>
> >>You can also find information about the bug which is #18756.
> >>
> >>Albert Chin wrote:
> >>
> >>    
> >>
> >>>I have an Intel S875WP1-E with FreeBSD 4.8-STABLE running Apache
> >>>2.0.48 prefork with mod_ldap enabled, built against 
> OpenLDAP 2.1.23.
> >>>I'm getting a SEGV when I have ldap caching enabled. It seems the
> >>>contents of the global util_ldap_cache is being corrupted. 
> If I set a
> >>>breakpoint at util_ald_cache_insert, I see this right before 
> >>>      
> >>>
> >>the SEGV:
> >>    
> >>
> >>> #0  util_ald_cache_insert (cache=0x30048018, payload=0x80c3540)
> >>>     at util_ldap_cache_mgr.c:390
> >>> #1  0x2841260d in util_ald_create_caches (st=0x80dad98, 
> >>>     url=0x8153600 "[AuthLDAPUrl argument]") at 
> >>>      
> >>>
> >>util_ldap_cache_mgr.c:275
> >>    
> >>
> >>> #2  0x28410952 in util_ldap_cache_checkuserid 
> >>>      
> >>>
> >>(r=0x814d050, ldc=0x80c3248, 
> >>    
> >>
> >>>     url=0x8153600 "[AuthLDAPUrl argument]", 
> >>>     basedn=0x81536b0 "[LDAP BASE DN]", scope=1, 
> >>>     attrs=0x81536d8, 
> >>>     filter=0xbfbfd768 "[LDAP QUERY STRING]", 
> >>>     bindpw=0x8153b56 "[PASSWORD]", binddn=0xbfbfd754, 
> >>>      
> >>>
> >>retvals=0xbfbff768)
> >>    
> >>
> >>>     at util_ldap.c:765
> >>> #3  0x28417bf5 in mod_auth_ldap_check_user_id (r=0x814d050)
> >>>     at mod_auth_ldap.c:366
> >>> ...
> >>>
> >>> gdb> print util_ldap_cache 
> >>> $37 = (util_ald_cache_t *) 0x30048018
> >>> gdb> print util_ldap_cache->maxentries
> >>> $38 = 675356296
> >>>
> >>>The 675356296 should be 50 (from util_ldap_cache_init in
> >>>util_ldap_cache.c). The SEGV comes from:
> >>> gdb> print util_ldap_cache->hash
> >>> $39 = (long unsigned int (*)()) 0
> >>>
> >>>What can I do to track this down?
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>    
> >>
> >
> >  
> >
> 
>