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:[EMAIL PROTECTED] > Sent: Tuesday, November 04, 2003 4:29 AM > To: [EMAIL PROTECTED] > 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:[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? > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > >
