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:[EMAIL PROTECTED] > >>Sent: Monday, November 03, 2003 12:37 AM > >>To: [EMAIL PROTECTED] > >>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? > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > >
