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 17:28:03 GMT
Hi Matthieu,

I was speaking about the actual code we saw in 2.0.47. I will try your patch
and see what happens.

Thanks,

Chou

> -----Original Message-----
> From: Matthieu Estrade [mailto:apache@moresecurity.org]
> Sent: Tuesday, November 04, 2003 4:29 AM
> To: dev@httpd.apache.org
> Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
> 
> 
> Hi Chou,
> 
> I dunno if you looked into the patch i pointed in my last 
> mail, but this 
> is what the patch is doing:
> 
> 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.
> 
> Could you tell me if you speak about my patch or about the 
> actual code 
> of util_ldap and mod_ldap ?
> I know the patch works with linux and it's broken with solaris, but i 
> don't have more feedback.
> 
> Matthieu
> 
> 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?
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>    
> >>
> >
> >  
> >
> 
> 

Mime
View raw message