openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#5492)
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. Used crypt to hash password. --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/html Content-Transfer-Encoding: 8bit <html><body> <DIV> <DIV>I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same.  </DIV> <DIV> </DIV> <DIV>Used crypt to hash password.</DIV></DIV></body></html> --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0--

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs