httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Estrade <apa...@moresecurity.org>
Subject Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Date Tue, 04 Nov 2003 12:29:04 GMT
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