- openldap-bugs - openldap.org

Re: (ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by hyc＠symas.com 30 Apr '08

30 Apr '08

huynh.tuan(a)comcast.net wrote: > Full_Name: Tuan Huynh > Version: 2.3.39 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.39.129.66) > > > My password is 10 characters long, however system allowed me to login as long as > I enter first 8 characters and it ignored the rest even if I enter garbage. For > example: > > my password is !thisIsATest! > when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk > > I used ppolicy and pwdMinLength is set at 8 Sounds like a configuration error in your Solaris system, or possibly a poor choice of password hash mechanism. I don't see any evidence of an OpenLDAP bug here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

Full_Name: Tuan Huynh Version: 2.3.39 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.39.129.66) My password is 10 characters long, however system allowed me to login as long as I enter first 8 characters and it ignored the rest even if I enter garbage. For example: my password is !thisIsATest! when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk I used ppolicy and pwdMinLength is set at 8

1 0

Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > When syncrepl and syncprov are both used on a glue database, the > contextCSN received from the syncrepl producers are not passed on to the > syncprov consumers when changes in subordinate databases are received. > The reason is that syncrepl queues the CSNs in the glue backend, while > syncprov fetches them from the backend where the changes are made. As a > consequence, the consumers will be passed a cookie without any csn > value. > > My first attempt at fixing this was to change syncprov to fetch the > queued csn values from the glue backend where it was used. But that > failed as other modules queues the csn values in their own backend when > they changes things. What other modules? Generally there cannot be any other sources of changes. > Instead I changed ctxcsn.c so that it always > queues them in the glue backend where syncprov is used. But I don't > feel that my understanding of this stuff is good enough to be sure that > this is the optimal solution.. I definitely don't like references to the syncprov overlay appearing in main slapd code like that. We need a different solution. At one point in the past, I had changed syncrepl.c to queue the CSNs in both places, but that seemed rather sloppy. Still, it may work best here. > Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE > test, should that have included an overlay_is_inst() clause as well? Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on that call. > Rein Tollevik > Basefarm AS > > Index: OpenLDAP/servers/slapd/ctxcsn.c > diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 > OpenLDAP/servers/slapd/ctxcsn.c:1.2 > --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 > +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 > @@ -37,67 +37,78 @@ > ) > { > struct slap_csn_entry *csne, *committed_csne = NULL; > + Backend *be = op->o_bd; > > if ( maxcsn ) { > BER_BVZERO( maxcsn ); > } > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_COMMIT; > break; > } > } > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; > if ( csne->ce_state == SLAP_CSN_PENDING ) break; > } > > if ( committed_csne&& maxcsn ) *maxcsn = committed_csne->ce_csn; > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_rewind_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be = op->o_bd; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_PENDING; > break; > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_graduate_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be; > > if ( op == NULL ) return; > if ( op->o_bd == NULL ) return; > > + be = op->o_bd; > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + > #if 0 > /* it is NULL when we get here from the frontendDB; > * alternate fix: initialize frontendDB like all other backends */ > - assert( op->o_bd->be_pcl_mutexp != NULL ); > + assert( be->be_pcl_mutexp != NULL ); > #endif > > - if ( op->o_bd->be_pcl_mutexp == NULL ) return; > + if ( be->be_pcl_mutexp == NULL ) return; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, > csne, ce_csn_link ); > Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", > csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); > @@ -110,7 +121,7 @@ > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > > return; > } > @@ -161,22 +172,25 @@ > struct berval *csn ) > { > struct slap_csn_entry *pending; > + Backend *be = op->o_bd; > > pending = (struct slap_csn_entry *) ch_calloc( 1, > sizeof( struct slap_csn_entry )); > > Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, > csn->bv_val, 0 ); > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > ber_dupbv(&pending->ce_csn, csn ); > ber_bvreplace_x(&op->o_csn,&pending->ce_csn, op->o_tmpmemctx ); > pending->ce_connid = op->o_connid; > pending->ce_opid = op->o_opid; > pending->ce_state = SLAP_CSN_PENDING; > - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, > pending, ce_csn_link ); > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > int > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5491) slapd crashes with ldappasswd
by Deepak.Cheema＠emerson.com 30 Apr '08

30 Apr '08

Full_Name: Deepak Cheema Version: 2.4.8 OS: Red Hat Linux 3.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.189.5.201) Just built, installed openldap 2.4.8 and slapd starts up fine using the following slapd -f slapd.conf -u root as root user on default port 389 [root@dl2k245 libexec]# ps -ef|grep slapd root 15065 1 0 15:31 ? 00:00:00 ./slapd -f /dbapps/informatica/l dap/etc/openldap/slapd.conf -u root The process stays up as long as I don't type the ldappasswd command to get the encrypted password a new user... once I type in ldappasswd... this is what happens.. [root@dl2k245 bin]# ldappasswd SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Can't contact LDAP server additional info: SASL(0): successful result: security flags do not match required [root@dl2k245 bin]# ps -ef|grep lapd root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd and the slapd process is no longer there... Any ideas why it might be happening or how to debug this? I tried dbg but it did not tell me much.. maybe I did not use it correctly... Any help is appreciated !

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > syncprov_findbase() must search the backend saved with the syncrepl operation, > not the one from the operation passed as argument. The backend in the op > argument can be a subordinate database, in which case the search for the base in > the superior database will fail, and syncrepl consumers will be force to do a an > unneccessary full refresh of the database. OK. > The patch at the end should fix > this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the > overlay_op_walk() call, which is the reason for the long pointer traversal to > find the correct bd_info to save and restore. But the overlay_op_walk call is only appropriate when the DB to be searched is the current database, and the current DB is an overlay DB structure. Your patch causes fc->fss->s_op->o_bd's bd_info pointer to change, which is not allowed. That's in the original backendDB, which must be treated as read-only since multiple threads may be accessing it. The correct approach here is to use a new local backendDB variable, copy the s_op->o_bd into it, and then just do a regular be_search invocation instead of using overlay_op_walk. But, this patch must not take effect on the first call to syncprov_findbase (which occurred in syncprov_op_search) - in that case, the current code is correct. So, you need to tweak things based on whether (s_flags & PS_IS_REFRESHING) is true or not - if true, this is the first search, and it should use the original code. Else, it must use be_search. > Rein Tollevik > Basefarm AS > > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 > 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 > @@ -404,7 +404,7 @@ > slap_callback cb = {0}; > Operation fop; > SlapReply frs = { REP_RESULT }; > - BackendInfo *bi; > + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; > int rc; > > fc->fss->s_flags ^= PS_FIND_BASE; > @@ -413,10 +413,8 @@ > fop = *fc->fss->s_op; > > fop.o_hdr = op->o_hdr; > - fop.o_bd = op->o_bd; > fop.o_time = op->o_time; > fop.o_tincr = op->o_tincr; > - bi = op->o_bd->bd_info; > > cb.sc_response = findbase_cb; > cb.sc_private = fc; > @@ -435,7 +433,7 @@ > fop.ors_filterstr = generic_filterstr; > > rc = overlay_op_walk(&fop,&frs, op_search, on->on_info, on ); > - op->o_bd->bd_info = bi; > + fc->fss->s_op->o_bd->bd_info = bi; > } else { > ldap_pvt_thread_mutex_unlock(&fc->fss->s_mutex ); > fc->fbase = 1; > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5489) Assert failed in slapd_clr_write()
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in > slapd_clr_write() failed, see the stack trace at the end. The > last log message (at loglevel stat) related to the socket was > "fd=657 closed (connection lost on write)". The comment where > slapd_daemon_task() calls connection_write() makes me believe > that slapd_clr_write() should not have use assert here. Remove > it or include it as a condition in the following if statement? How frequently can you reproduce this? I'm tempted to say move the assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still triggers. > > Rein Tollevik > Basefarm AS > > > Program terminated with signal 6, Aborted. > (gdb) where > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 > #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 > #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 > #5 0x080726d7 in connection_write (s=657) at connection.c:1814 > #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 > #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 > #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6 > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5490) accesslog_response segfault
by quanah＠zimbra.com 30 Apr '08

30 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Repeated coredumps from slapd, in the accesslog_response function. Core #1: Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://zimbra-adm.'. Program terminated with signal 11, Segmentation fault. (gdb) thr apply all bt Thread 10 (process 7511): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 12519): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 12520): #0 0x000000376980af8b in ?? () #1 0x0000000040fff920 in ?? () #2 0x0000000040fff6e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe611c0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c900, rs=0x41000ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c900, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c900, rs=0x41000ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c900, rs=0x41000ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0xd97c900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x38) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 12521): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c600, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c600, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c600, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c600, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xd97c600) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 12524): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7768c00, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7768c00, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7768c00, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7768c00, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x7768c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x3f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 12525): #0 0x000000000045569b in slap_acl_mask (a=0x8b4000, mask=0x430040d8, op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, nmatch=100, matches=0x43003da0, count=1, state=0x0) at acl.c:1496 #1 0x00000000004538ca in access_allowed_mask (op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, access=ACL_READ, state=0x0, maskp=0x0) at acl.c:698 #2 0x000000000043fa48 in slap_send_search_entry (op=0x43004ab0, rs=0x43004780) at result.c:737 #3 0x0000002a979a0647 in syncprov_sendresp (op=0x43004ab0, opc=0x43004850, so=0x791ff30, e=0x430048b8, mode=1) at syncprov.c:784 #4 0x0000002a979a09a2 in syncprov_qplay (op=0x43004ab0, on=0xddec40, so=0x791ff30) at syncprov.c:853 #5 0x0000002a979a0be6 in syncprov_qtask (ctx=0x43004e10, arg=0x2178f00) at syncprov.c:898 #6 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #7 0x0000003769806137 in ?? () #8 0x0000000000000000 in ?? () Thread 4 (process 14050): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x22e2d90) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x23d0900, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x23d0900, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x23d0900, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x23d0900, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0x23d0900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x3c) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 14051): #0 0x000000376980bf1c in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 14052): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x214e6c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7657c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7657c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7657c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7657c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7657c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x36) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 12522): #0 0x0000002a97aac75a in accesslog_response (op=0xd97c000, rs=0x42002ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0xd97c000, rs=0x42002ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0xd97c000, rs=0x42002ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0xd97c000, rs=0x42002ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0xd97c000, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0xd97c000, rs=0x42002ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0xd97c000, rs=0x42002ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0xd97c000) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x23) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () Core #2: Thread 10 (process 11473): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 15458): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 15460): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcadbc00, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcadbc00, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcadbc00, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcadbc00, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xcadbc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x32) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 15461): #0 0x000000376980af8b in ?? () #1 0x0000000042001920 in ?? () #2 0x00000000420016e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64380) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2300, rs=0x42002ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2300, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2300, rs=0x42002ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2300, rs=0x42002ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0x34d2300) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x2b) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 15463): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2900, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2900, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2900, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2900, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x34d2900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 15724): #0 0x000000376980af8b in ?? () #1 0x0000000043003920 in ?? () #2 0x00000000430036e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616dc8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75900, rs=0x43004ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75900, rs=0x43004ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75900, rs=0x43004ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75900, rs=0x43004ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43004e10, arg_v=0xcb75900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43004e10, argv=0x31) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 4 (process 15725): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616fc0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75c00, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75c00, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75c00, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75c00, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0xcb75c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x2f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 16249): #0 0x000000376980af8b in ?? () #1 0x0000000044005920 in ?? () #2 0x00000000440056e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xcb1ff50) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcbccc00, rs=0x44006ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcbccc00, rs=0x44006ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcbccc00, rs=0x44006ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcbccc00, rs=0x44006ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44006e10, arg_v=0xcbccc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44006e10, argv=0x24) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 2 (process 16251): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xdcd06c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7661c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7661c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7661c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7661c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7661c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x35) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 15459): #0 0x0000002a97aac75a in accesslog_response (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0x34d2c00, rs=0x41000ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0x34d2c00, rs=0x41000ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0x34d2c00, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0x34d2c00, rs=0x41000ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0x34d2c00, rs=0x41000ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0x34d2c00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x2e) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () 2 more cores that looks similar if desired.

1 0

(ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in slapd_clr_write() failed, see the stack trace at the end. The last log message (at loglevel stat) related to the socket was "fd=657 closed (connection lost on write)". The comment where slapd_daemon_task() calls connection_write() makes me believe that slapd_clr_write() should not have use assert here. Remove it or include it as a condition in the following if statement? Rein Tollevik Basefarm AS Program terminated with signal 6, Aborted. (gdb) where #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 #5 0x080726d7 in connection_write (s=657) at connection.c:1814 #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6

1 0

(ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncrepl and syncprov are both used on a glue database, the contextCSN received from the syncrepl producers are not passed on to the syncprov consumers when changes in subordinate databases are received. The reason is that syncrepl queues the CSNs in the glue backend, while syncprov fetches them from the backend where the changes are made. As a consequence, the consumers will be passed a cookie without any csn value. My first attempt at fixing this was to change syncprov to fetch the queued csn values from the glue backend where it was used. But that failed as other modules queues the csn values in their own backend when they changes things. Instead I changed ctxcsn.c so that it always queues them in the glue backend where syncprov is used. But I don't feel that my understanding of this stuff is good enough to be sure that this is the optimal solution.. Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE test, should that have included an overlay_is_inst() clause as well? Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/ctxcsn.c diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 OpenLDAP/servers/slapd/ctxcsn.c:1.2 --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 @@ -37,67 +37,78 @@ ) { struct slap_csn_entry *csne, *committed_csne = NULL; + Backend *be = op->o_bd; if ( maxcsn ) { BER_BVZERO( maxcsn ); } - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_COMMIT; break; } } - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; if ( csne->ce_state == SLAP_CSN_PENDING ) break; } if ( committed_csne && maxcsn ) *maxcsn = committed_csne->ce_csn; - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_rewind_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be = op->o_bd; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_PENDING; break; } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_graduate_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be; if ( op == NULL ) return; if ( op->o_bd == NULL ) return; + be = op->o_bd; + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + #if 0 /* it is NULL when we get here from the frontendDB; * alternate fix: initialize frontendDB like all other backends */ - assert( op->o_bd->be_pcl_mutexp != NULL ); + assert( be->be_pcl_mutexp != NULL ); #endif - if ( op->o_bd->be_pcl_mutexp == NULL ) return; + if ( be->be_pcl_mutexp == NULL ) return; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, csne, ce_csn_link ); Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); @@ -110,7 +121,7 @@ } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); return; } @@ -161,22 +172,25 @@ struct berval *csn ) { struct slap_csn_entry *pending; + Backend *be = op->o_bd; pending = (struct slap_csn_entry *) ch_calloc( 1, sizeof( struct slap_csn_entry )); Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, csn->bv_val, 0 ); - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); ber_dupbv( &pending->ce_csn, csn ); ber_bvreplace_x( &op->o_csn, &pending->ce_csn, op->o_tmpmemctx ); pending->ce_connid = op->o_connid; pending->ce_opid = op->o_opid; pending->ce_state = SLAP_CSN_PENDING; - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, pending, ce_csn_link ); - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } int

1 0

(ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein syncprov_findbase() must search the backend saved with the syncrepl operation, not the one from the operation passed as argument. The backend in the op argument can be a subordinate database, in which case the search for the base in the superior database will fail, and syncrepl consumers will be force to do a an unneccessary full refresh of the database. The patch at the end should fix this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the overlay_op_walk() call, which is the reason for the long pointer traversal to find the correct bd_info to save and restore. Rein Tollevik Basefarm AS diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 @@ -404,7 +404,7 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -413,10 +413,8 @@ fop = *fc->fss->s_op; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -435,7 +433,7 @@ fop.ors_filterstr = generic_filterstr; rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + fc->fss->s_op->o_bd->bd_info = bi; } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

This is a multi-part message in MIME format. --------------080809000906010300090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > Thanks. Please try HEAD again. No way. new testrun directory in ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz backtrace attached --------------080809000906010300090306 Content-Type: text/plain; name="bt.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="bt.txt" Program terminated with signal 11, Segmentation fault. #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 588 undef = f->f_choice & SLAPD_FILTER_UNDEFINED; (gdb) thr apply all bt full Thread 5 (process 11932): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x0072f605 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011e907 in ldap_pvt_thread_join (thread=18434960, thread_return=0x0) at thr_posix.c:197 No locals. #3 0x080766b2 in slapd_daemon () at daemon.c:2644 listener_tid = 18434960 rc = 0 #4 0x0805badc in main (argc=8, argv=0xbfce4da4) at main.c:946 i = -1 no_detach = 1 rc = -12 urls = 0x9210018 "ldap://localhost:9012/" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 8 g_argv = (char **) 0xbfce4da4 configfile = 0x0 configdir = 0x9210008 "./slapd.d" serverName = 0xbfce5306 "lt-slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x812e057 "" l = 1347374360 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main" Thread 4 (process 11947): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x00670346 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #2 0x08075aa1 in slapd_daemon_task (ptr=0x0) at daemon.c:2281 ns = 1 at = 0 nfds = 7 revents = (struct epoll_event *) 0x9213d78 tvp = (struct timeval *) 0x11942fc cat = {tv_sec = 1209559064, tv_usec = 0} i = 0 nwriters = 0 now = 1209559054 tv = {tv_sec = 10, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x92895b0 l = 2 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #3 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 3 (process 12114): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 22633360, ltu_key = {{ltk_key = 0x8079056, ltk_data = 0x926ab48, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x80dc7a5, ltk_data = 0x9268408, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a890, ltk_free = 0x80910e8 <slap_op_q_destroy>}, { ltk_key = 0x9294ac0, ltk_data = 0xb7b821d4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6196008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 165 hash = 5272741 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 2 (process 12129): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 60083088, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9266bf8, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x8079056, ltk_data = 0x927ba30, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a558, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b823b4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6997008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 306 hash = 5400882 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (process 12939): #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 i = 153708648 p = (Filter *) 0xb tmp = {bv_len = 0, bv_val = 0x9296868 "\b\220\231�\b\220\231�\b\220��\001"} value = {bv_len = 153577944, bv_val = 0x0} len = 44136616 choice = 134851750 undef = 153577944 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #1 0x0807ef20 in filter2bv_x (op=0x2a17dac, f=0x92dd360, fstr=0x2a17df0) at filter.c:742 i = 40 p = (Filter *) 0x32383833 tmp = {bv_len = 9, bv_val = 0x92769d8 "�]-\t"} value = {bv_len = 153998176, bv_val = 0x0} len = 94946797 choice = 160 undef = 0 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #2 0x080e97eb in syncrepl_del_nonpresent (op=0x2a17dac, si=0x9294348, uuids=0x0, sc=0x2a17c08, m=0) at syncrepl.c:2444 f = (Filter *) 0x92dd36c i = 1 cf = (Filter *) 0x92dd360 of = (Filter *) 0x92994e8 be = (Backend *) 0x92891f8 cb = {sc_next = 0x0, sc_response = 0x80eb85b <nonpresent_callback>, sc_cleanup = 0, sc_private = 0x9294348} rs_search = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} np_list = (struct nonpresent_entry *) 0x92994e8 np_prev = (struct nonpresent_entry *) 0x0 rc = 44137248 an = {{an_name = {bv_len = 9, bv_val = 0x922ed58 "entryUUID"}, an_desc = 0x922edf8, an_oc_exclude = 0, an_oc = 0x0}, {an_name = {bv_len = 0, bv_val = 0x0}, an_desc = 0x0, an_oc_exclude = 0, an_oc = 0x0}} pdn = {bv_len = 0, bv_val = 0x0} csn = {bv_len = 4294967295, bv_val = 0x15a4b8 "P\223\004"} #3 0x080e4a27 in do_syncrep2 (op=0x2a17dac, si=0x9294348) at syncrepl.c:952 rctrls = (LDAPControl **) 0x92994e8 rctrlp = (LDAPControl *) 0x92ddf18 berbuf = { buffer = "\002\000\001\000\005\001", '\0' <repeats 14 times>, "X4'\t\2304'\t\2304'\t", '\0' <repeats 32 times>, "�|�\002\000\000\000\000\000\000\000\000�|�\002\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\021\000\000\000�h)\t\021\000\000\000\210�%\t�|�\002", '\0' <repeats 16 times>, "��\"\t8\226(\tpb)\t\001", '\0' <repeats 15 times>, "\n\000\000\0008�\"\t��\"\t\000\000\000\000��\025\000\000\000\000\000\000\000\000\000\000|�\002\000\000\000\000\001\000\000\000�D)\t\001\000\000\000��\025\000x}�\002\024\021\024\000\210\220(\t\001\000\000\000�}�\002\b9\016\b\001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 5.5384093382201037e-312, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x2a17c44 msg = (LDAPMessage *) 0x92d6718 retoid = 0x9297730 "all alumni assoc staff" retdata = (struct berval *) 0x92734f8 entry = (Entry *) 0x92cbf2c syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0x92d5dff "\t\020"} syncCookie = {ctxcsn = 0x92ddf30, octet_str = {bv_len = 60, bv_val = 0x92dcf08 "rid=004,sid=002,csn=20080430123714.430853Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9277d68, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x92734e0, octet_str = {bv_len = 60, bv_val = 0x92966e0 "rid=004,sid=002,csn=20080430123714.247229Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9297bd8, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 60, bv_val = 0x927345c "ames a jones 2,ou=alumni association,ou=people,dc=example,dc=com"} rc = 101 err = 0 len = 0 psub = (struct berval *) 0x9289190 modlist = (Modifications *) 0x92748b0 match = -1 m = 0 tout_p = (struct timeval *) 0x0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x9272478 si_tag = 163 #4 0x080e5c1f in do_syncrepl (ctx=0x2a1820c, arg=0x92895b0) at syncrepl.c:1276 rtask = (struct re_s *) 0x92895b0 si = (syncinfo_t *) 0x9294348 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_peer_name = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_listener = 0x8134fa0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x808d3c3 <slap_send_ldap_result>, c_send_search_entry = 0x808e0c3 <slap_send_search_entry>, c_send_search_reference = 0x808fe46 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x2a17e84, o_tag = 99, o_time = 1209559044, o_tincr = 18, o_bd = 0x92891f8, o_req_dn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_req_ndn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 44136992, bv_val = 0x92dd360 "�"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x2a17a20 "\t"}, rs_newSup = 0x92dd360, rs_nnewSup = 0x5a8c5ed}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x2a17a20, rs_filter = 0x92dd360, rs_filterstr = {bv_len = 94946797, bv_val = 0xafb97008 "(&(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unknown)(?=unknown)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unkn"...}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = { bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 44136992, bv_val = 0x92dd360 "�"}, rs_mods = 0x5a8c5ed, rs_modtail = 0xafb97008}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 16 times>, "\002", '\0' <repeats 14 times>, o_controls = 0x2a17fb0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 28, bv_val = 0x9289570 "cn=Manager,dc=example,dc=com"}, sai_ndn = {bv_len = 28, bv_val = 0x92891c8 "cn=manager,dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x2a17afc, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x2a18030, oh_msgid = 0, oh_protocol = 3, oh_tid = 44141456, oh_threadctx = 0x2a1820c, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x817c834, oh_counters = 0x81c2900, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x0 <repeats 32 times>}} op = (Operation *) 0x2a17dac rc = 0 dostop = 0 do_setup = 0 s = 18 i = 44138952 defer = 1 fail = 0 be = (Backend *) 0x92891f8 #5 0x0011d72e in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x9266868 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 44141456, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9296868, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b822c4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb7198008, ltk_free = 0xbf9b08}, {ltk_key = 0x8079056, ltk_data = 0x9288c68, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x9273cc0, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 606 hash = 5329502 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #6 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #7 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) --------------080809000906010300090306--

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

Here it is again. HEAD code checked out this morning. I'm able to reproduce the crash fairly often. testrun directory uploaded at ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430.tgz the core file is in testrun/con

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 29 Apr '08

29 Apr '08

Howard Chu wrote: >> Looking at the log snippet above, I can see in the "syncprov_sendresp" >> lines >> that the cookie appears to be empty. This does appear to be similar to >> ITS#5432, > > I don't see that in the snippet above. Seems unrelated. Okay. I was just querying whether it was related to the fact that the cookie= field appeared blank similar to the ITS#5432. > "info threads" would probably be a useful start. And "bt full". No problem. I've created a file containing the same snippet from the log file and the extra information requested above, and uploaded it to http://pastebin.siriusit.co.uk/openldap-its5486-detail.txt to help preserve formatting. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by hyc＠symas.com 28 Apr '08

28 Apr '08

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.8cvs-RE24-2008-04-15 > OS: RHEL4, x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.207.197.142) > > > Hi there, > > In order to resolve issues experienced with syncrepl/glue on an existing > openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of > openldap RE24 branch taken from 2008-04-15 on one of our test systems. > > Unfortunately, we are still seeing random segfaults occurring roughly once a day > which appear to point towards the syncprov overlay once again. At the moment, we > are having difficulty reproducing the fault under test conditions, but if > openldap is left running long enough then it is possible to obtain a core dump. > > The issue is occurring with a server, pelican, which is configured using the > syncprov overlay to a number of subordinates for different parts of the tree. > The relevant log snippet follows: > > Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: > cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing > 0xa12ee70 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Looking at the log snippet above, I can see in the "syncprov_sendresp" lines > that the cookie appears to be empty. This does appear to be similar to ITS#5432, I don't see that in the snippet above. Seems unrelated. > although this claims to have been fixed by a commit on the 21st March (and hence > the fix would be included within our CVS checkout). Further information can be > provided on request. "info threads" would probably be a useful start. And "bt full". -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 28 Apr '08

28 Apr '08

ando(a)sys-net.it wrote: > raphael.ouazana(a)linagora.com wrote: >> Hi, >> >> Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >>> I updated RE24 this morning with a couple of fixes from Howard. >>> >>> See if you can still repo, thanks. >> It still seems to fail, after more than 100 runs: > > It appears from your logs that the entry > > "cn=ITD Staff,ou=Groups,dc=example,dc=com" > > is being added first, and then removed from server 3, probably related > to some issue in sync replication. Seems like the consumer has received a cookie from one provider, while receiving a newer entry from the other provider. During the nonpresent search the new entry is found and removed. So we need to restrict the filter in the nonpresent search to only return entries older than the cookie context. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 28 Apr '08

28 Apr '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-04-15 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, In order to resolve issues experienced with syncrepl/glue on an existing openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of openldap RE24 branch taken from 2008-04-15 on one of our test systems. Unfortunately, we are still seeing random segfaults occurring roughly once a day which appear to point towards the syncprov overlay once again. At the moment, we are having difficulty reproducing the fault under test conditions, but if openldap is left running long enough then it is possible to obtain a core dump. The issue is occurring with a server, pelican, which is configured using the syncprov overlay to a number of subordinates for different parts of the tree. The relevant log snippet follows: Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing 0xa12ee70 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 The backtrace obtained from the core file looks like this: Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/openldap/syncprov-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/openldap/syncprov-2.4.so.2.0.4.debug...done. done. Loaded symbols for /usr/lib/openldap/syncprov-2.4.so.2 #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 355 rc = on->on_bi.bi_entry_get_rw( op, dn, (gdb) bt #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 #1 0x00b187ac in syncprov_qtask (ctx=0x7e3ef2a0, arg=0xa02f708) at ../../../../servers/slapd/overlays/syncprov.c:871 #2 0x0817a277 in ldap_int_thread_pool_wrapper (xpool=0x9db94d0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00acb371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x00944ffe in clone () from /lib/tls/libc.so.6 (gdb) The server pelican is configured using both the syncprov & glue overlays, while the subordinate for ou=V,ou=W,ou=X,dc=Y,dc=Z is a simple syncrepl declaration of type refreshAndPersist. Looking at the log snippet above, I can see in the "syncprov_sendresp" lines that the cookie appears to be empty. This does appear to be similar to ITS#5432, although this claims to have been fixed by a commit on the 21st March (and hence the fix would be included within our CVS checkout). Further information can be provided on request. Many thanks, Mark.

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)tollevik.no wrote: > On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > >> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). >> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. >> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if >> and only if rs.sr_entry->e_private != NULL. Which is possibly true with >> back-bdb but seems a shaky assumption in general.) > > Almost, except that it triggers an abort.. Using be_entry_release_r() was > not correct, as it ended up calling entry_free(). It works if I changes > it to use overlay_entry_release_ov() instead, as in the alternative patch > at the end. > > I have put a test script that shows this deadlock on: > > ftp://ftp.openldap.org/incoming/test053-syncprov-glue > > It deadlocks without this patch, it and the rest of the test suite succeed > with it :-) I haven't tested it in production though.. This last patch is now committed to HEAD. I am ignoring the first patch; it is unsafe because it unlocks the si_csn_rwlock too soon. (si_ctxcsn is being used directly in the modify request and must be held consistent until that completes.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5484) Remove runqueue task when freeing syncops bugfix
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: > Submission from: (NULL) (81.93.160.250) > > > We have seen occasional seg. faults in syncprov_qtask() where it was > passed a syncops pointer containing garbage in its arg. It looks as > this could happen if syncprov_free_syncop is called to free an abandoned > operation. I hope the patch at the should fix this, it makes sure to > remove the syncops->s_qtask (if any) from the runqueue before freeing > the syncops itself. I think this could also cause ITS#5452. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > > While I was here, I added myself to the aknowledgements in the man page. > Applied to HEAD (with minor changes); please test. A quick test suggests it works as intended. Any chance to have it in an upcoming 2.4 release? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

Emmanuel Dreyfus wrote: > Sorry. The new patch was uploaded in FTP: > manu-20080426.patch > > While I was here, I added myself to the aknowledgements in the man page. Applied to HEAD (with minor changes); please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > I'm considering your patch for inclusion in HEAD code; I see that in > your patch you didn't follow the IPR notice as indicated in the > contributing guidelines. Please resubmit the patch adding at the top > the notices illustrated in > <http://www.openldap.org/devel/contributing.html#notice>: > > - notice of origin > - rights statement Sorry. The new patch was uploaded in FTP: manu-20080426.patch While I was here, I added myself to the aknowledgements in the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5470) Sporadic failures with RE24
by ando＠sys-net.it 26 Apr '08

26 Apr '08

raphael.ouazana(a)linagora.com wrote: > Hi, > > Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >> I updated RE24 this morning with a couple of fixes from Howard. >> >> See if you can still repo, thanks. > > It still seems to fail, after more than 100 runs: It appears from your logs that the entry "cn=ITD Staff,ou=Groups,dc=example,dc=com" is being added first, and then removed from server 3, probably related to some issue in sync replication. Can you enable "sync" log when running the tests? SLAPD_DEBUG="sync,stats,args,trace" ./run test050 p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

manu(a)netbsd.org wrote: > URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch > This patch adds attribute remapping capability to slapo-dynlist. Emmanuel, I'm considering your patch for inclusion in HEAD code; I see that in your patch you didn't follow the IPR notice as indicated in the contributing guidelines. Please resubmit the patch adding at the top the notices illustrated in <http://www.openldap.org/devel/contributing.html#notice>: - notice of origin - rights statement p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5485) Header files contain insufficient/outdated entries that prevent usage with Kerberos
by hyc＠symas.com 24 Apr '08

24 Apr '08

The ITS is for tracking issues in OpenLDAP software. Nothing in this report indicates any bug in OpenLDAP software. Most likely you've found a bug in MIT Kerberos. I suggest you contact the MIT folks. This ITS will be closed. brian.peters(a)analog.com wrote: > Full_Name: Brian Peters > Version: 2.3.39 > OS: SPARC Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.71.23.54) > > > I am attempting to compile Samba using active directory. This entails using LDAP > and Kerberos during set up. The native versions on Solaris 10 are insufficient > due to a lack of ldap_initialize in those header files. I am using the most > recent versions of both Openldap (2.3.39) and Kerberos (krb5-1.6.3). The error > manifests itself when compiling Kerberos. Before we proceed any further let's > first lay down the foundation of the data. > > Openldap was configured using the following: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openlda > p-2.3.39 --without-bdb --disable-bdb --enable-null --disable-slapd > --enable-shar > ed --with-shared=yes > > CFLAGS -D_AVL_H > > Kerberos using: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/kerberos/krb5-1.6.3 > --with-ldap --enable-shared > > > All important environment variables have been set specifically for each > configuration (CPPFLAGS,LDFLAGS,PATH,LD_LIBRARY_PATH,CFLAGS). > > I have confirmed in the config.log files that each is pulling the correct files > during the attempted compile. The issue appears when running gmake. Below is the > important portion it returns. > > ... > In file included from kdb_ldap.c:37: > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.c:491: warning: missing braces around initializer > kdb_ldap.c:491: warning: (near initialization for > `kldap_init_fn__once.once.o.__pthread_once_pad') > kdb_ldap.c:500: warning: no previous prototype for 'kldap_ensure_initialized' > gmake[2]: *** [kdb_ldap.so] Error 1 > gmake[2]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap/libkdb_ldap' > gmake[1]: *** [all-recurse] Error 1 > gmake[1]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap' > gmake: *** [all-recurse] Error 1 > > > At this point I am at a bit of a loss on how to proceed. Any advice on a fix or > versions of each to roll back to would be greatly appreciated. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 24 Apr '08

24 Apr '08

Hi, Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : > I updated RE24 this morning with a couple of fixes from Howard. > > See if you can still repo, thanks. It still seems to fail, after more than 100 runs: Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Using ldapsearch to read config from consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved configs from producer and consumer... Comparing retrieved configs from producer and consumer2... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Using ldapsearch to read all the entries from the consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved entries from producer and consumer... Comparing retrieved entries from producer and consumer2... test failed - producer and consumer2 databases differ I sent the testrun directory through FTP: ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-20080424.tgz Regards, Raphaël Ouazana.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs