httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CHOU,TAIR-SHIAN (HP-Cupertino,ex1)" <tair-shian_c...@am.exch.hp.com>
Subject RE: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Date Tue, 04 Nov 2003 01:49:52 GMT
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?
> >
> >  
> >
> 
> 

Mime
View raw message