- openldap-bugs - openldap.org

Re: (ITS#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

--On Saturday, March 21, 2009 7:09 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: RE24 3/19/2009 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> While testing various load scenarios, slapadd deadlocked on me. > > The trace for thread 1 and 2 look identical, so I'm assuming they're the > same thread. In that case I see 3 tool threads running. How many did you > have configured? If 1 and 2 are really different threads (certainly their > thread IDs look quite different), then there's something very wrong in > the thread library... > > print bdb_tool_index_tcount > (gdb) print bdb_tool_index_tcount $1 = 1 > It looks like one thread has exited early. I'm not sure how that can > happen since the only way for any index thread to exit is if > slapd_shutdown is set. Is it set? (gdb) print slapd_shutdown $2 = 0 It's configured with 4 tool threads. --Quanah >> (gdb) thr apply all bt >> >> Thread 5 (Thread 1106889024 (LWP 9361)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1124 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 4 (Thread 1115281728 (LWP 9362)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 3 (Thread 1123674432 (LWP 9363)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized >> # out>, >> ptr=<value optimized out>) at tools.c:1147 >> # 2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper >> # (xpool=0x17e07fd0) at >> ../../../libraries/libldap_r/tpool.c:663 >> # 3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 >> # 4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 >> >> Thread 2 (Thread 1132067136 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> >> Thread 1 (Thread 47794824997056 (LWP 9360)): >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> # 1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, >> # txn=<value >> optimized out>, e=0x2b7b521d2068) at tools.c:475 >> # 2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, >> # e=0x2b7b521d2068, >> text=0x7fff93960cc0) at tools.c:545 >> # 3 0x00000000004906f9 in slapadd (argc=<value optimized out>, >> argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 >> # 4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at >> ../../../servers/slapd/main.c:391 >> # 0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6029) slapadd lockup
by hyc＠symas.com 21 Mar '09

21 Mar '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 3/19/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > While testing various load scenarios, slapadd deadlocked on me. The trace for thread 1 and 2 look identical, so I'm assuming they're the same thread. In that case I see 3 tool threads running. How many did you have configured? If 1 and 2 are really different threads (certainly their thread IDs look quite different), then there's something very wrong in the thread library... print bdb_tool_index_tcount It looks like one thread has exited early. I'm not sure how that can happen since the only way for any index thread to exit is if slapd_shutdown is set. Is it set? > > (gdb) thr apply all bt > > Thread 5 (Thread 1106889024 (LWP 9361)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1124 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1115281728 (LWP 9362)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1123674432 (LWP 9363)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, > ptr=<value optimized out>) at tools.c:1147 > #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at > ../../../libraries/libldap_r/tpool.c:663 > #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1132067136 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > > Thread 1 (Thread 47794824997056 (LWP 9360)): > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value > optimized out>, e=0x2b7b521d2068) at tools.c:475 > #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, > text=0x7fff93960cc0) at tools.c:545 > #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, > argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 > #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at > ../../../servers/slapd/main.c:391 > #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 -- -- 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#6029) slapadd lockup
by quanah＠zimbra.com 21 Mar '09

21 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/19/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) While testing various load scenarios, slapadd deadlocked on me. (gdb) thr apply all bt Thread 5 (Thread 1106889024 (LWP 9361)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f27de9 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1124 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1115281728 (LWP 9362)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1123674432 (LWP 9363)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28163 in bdb_tool_index_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1147 #2 0x00002b781715a2ca in ldap_int_thread_pool_wrapper (xpool=0x17e07fd0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00002b78178fe2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1132067136 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 Thread 1 (Thread 47794824997056 (LWP 9360)): #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7819f28014 in bdb_tool_index_add (op=0x7fff93950310, txn=<value optimized out>, e=0x2b7b521d2068) at tools.c:475 #2 0x00002b7819f28970 in hdb_tool_entry_put (be=0x17f39240, e=0x2b7b521d2068, text=0x7fff93960cc0) at tools.c:545 #3 0x00000000004906f9 in slapadd (argc=<value optimized out>, argv=0x7fff93960ec8) at ../../../servers/slapd/slapadd.c:350 #4 0x0000000000416c59 in main (argc=6, argv=0x7fff93960ec8) at ../../../servers/slapd/main.c:391 #0 0x00002b7817902496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by rein＠OpenLDAP.org 20 Mar '09

20 Mar '09

adrien.futschik(a)atosorigin.com wrote: >> Some changes have been made in the syncprov overlay's queue management in >> CVS HEAD. The test050 script has also been changed to test up to 9 masters, >> and it passes for me with several hundred iterations of 9 servers. (Some of >> the timing delays have to be increased though.) >> > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have > problems with some entries not being added. There are important bugfixes committed after 10/03/09, including fixes to this ITS. As of now you should test the RE24 branch, which is being prepared for an upcoming 2.4.16 release. Rein

1 0

Re: Fw: Re: (ITS#5988) entries skipped in n-way mutimaster replication
by adrien.futschik＠atosorigin.com 20 Mar '09

20 Mar '09

--Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik --Boundary-00=_8B4wJH+c2cGJw4l Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:8pt; font-weight:400; font-style:normal;">> Some changes have been made in the syncprov overlay's queue management in > CVS HEAD. The test050 script has also been changed to test up to 9 masters, > and it passes for me with several hundred iterations of 9 servers. (Some of > the timing delays have to be increased though.) > I have tested the HEAD version of OpenLDAP (10/03/09 - 14:48) and I still have problems with some entries not being added. I did not change my configuration. Here is an example of what I see in the log files : on M2 (where the entry is added) : [...] conn=32 fd=28 ACCEPT from IP=163.106.38.124:49986 (IP=163.106.38.92:9012) conn=32 op=0 BIND dn="cn=admin,c=fr" method=128 conn=32 op=0 BIND dn="cn=admin,c=fr" mech=SIMPLE ssf=0 conn=32 op=0 RESULT tag=97 err=0 text= conn=32 op=1 ADD dn="cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr" slap_queue_csn: queing 0x41000360 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 conn=32 op=1 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x2aaab00457e0 20090320101016.082209Z#000000#002#000000 conn=32 op=2 UNBIND conn=32 fd=28 closed [...] on M1 : [...] do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=001,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] do_syncrep2: cookie=rid=012,sid=001,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] on M3 : [...] do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x1b35e3d0 20090320101016.082209Z#000000#002#000000 syncprov_sendresp: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x1b35d660 20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 be_add (0) do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=003,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=014 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=014 NEW_COOKIE: rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=003,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 [...] on M4 : [...] do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.082209Z#000000#002#000000 syncrepl_entry: rid=012 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.075365Z#000000#001#000000 dn_callback : entries have identical CSN cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.075365Z#000000#001#000000 slap_queue_csn: queing 0x38c1610 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client114(a)laposte.net,ou=clients,o=edf,c=fr) slap_graduate_commit_csn: removing 0x38bdce0 20090320101016.075365Z#000000#001#000000 slap_graduate_commit_csn: removing 0x38c20d0 20090320101016.075365Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=012 be_search (0) syncrepl_entry: rid=012 cn=M2client24(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad0008c70 20090320101016.082209Z#000000#002#000000 slap_graduate_commit_csn: removing 0x2aaad0009ff0 20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac40234b0 20090320101016.118097Z#000000#001#000000 slap_queue_csn: queing 0x2aaad00032c0 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=012 be_add (0) slap_graduate_commit_csn: removing 0x2aaac40270f0 20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.118097Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad000b770 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.118097Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client115(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.075365Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.075365Z#000000#001#000000 do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr syncrepl_entry: rid=011 cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.162183Z#000000#001#000000 slap_queue_csn: queing 0x2aaad000a710 20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.162183Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.118097Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.118097Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaac4027050 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (0) slap_graduate_commit_csn: removing 0x2aaad0009fb0 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 be_add (68) dn_callback : entries have identical CSN cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=013 entry unchanged, ignored (cn=M1client116(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: cookie=rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=011 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=013 be_search (0) syncrepl_entry: rid=013 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaad000a660 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr slap_queue_csn: queing 0x2aaac4018760 20090320101016.205384Z#000000#001#000000 slap_graduate_commit_csn: removing 0x2aaad0008a50 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=013 be_add (0) slap_graduate_commit_csn: removing 0x2aaac4027960 20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=003,csn=20090320101016.205384Z#000000#001#000000 syncprov_sendresp: cookie=rid=014,sid=002,csn=20090320101016.205384Z#000000#001#000000 do_syncrep2: cookie=rid=012,sid=004,csn=20090320101016.162183Z#000000#001#000000 do_syncrep2: rid=012 CSN too old, ignoring 20090320101016.162183Z#000000#001#000000 syncrepl_entry: rid=011 be_add (68) dn_callback : entries have identical CSN cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr 20090320101016.205384Z#000000#001#000000 syncrepl_entry: rid=011 entry unchanged, ignored (cn=M1client117(a)laposte.net,ou=clients,o=edf,c=fr) do_syncrep2: rid=011 LDAP_RES_INTERMEDIATE - NEW_COOKIE do_syncrep2: rid=011 NEW_COOKIE: rid=011,sid=004,csn=20090320101016.205384Z#000000#001#000000;20090320101016.082209Z#000000#002#000000 do_syncrep2: cookie=rid=013,sid=004,csn=20090320101016.082209Z#000000#002#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090320101016.082209Z#000000#002#000000 [...] Do you have any idea what's going on ? I hoppe this will help Adrien Futschik</body></html> --Boundary-00=_8B4wJH+c2cGJw4l--

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 19 Mar '09

19 Mar '09

Howard Chu wrote: > Philip Guenther wrote: >> On Mon, 30 Apr 2007, Howard Chu wrote: >>> guenther+ldapdev(a)sendmail.com wrote: >> ... >>>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>>> section 3.1.3) and will terminate the connection if they don't match >>>> - 'try' is the same as 'demand' and 'hard' >>> Not quite. With both "allow" and "try" it's OK if the server provides no >>> certificate. >> >> That's true of 'demand' and 'hard' as well. The only difference between >> 'try' and 'demand' in the code is that the latter passes >> SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that >> flag has NO EFFECT on SSL clients. This is documented on the >> SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source >> for it. >> >> If you don't believe me, I suggest you try configuring your server to >> accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) >> and give ldapsearch a whirl with >> LDAPTLS_REQCERT=hard >> LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA >> >> in your environment. That's what I did. > > When this text was written, there was no support for anonymous cipher suites. > So the meaning of the text is: assuming a cipher suite that actually uses > certificates, the client would proceed even if the server didn't provide a > cert. It's entirely possible that this circumstance has been overcome by other > developments. Most likely this hasn't been a valid use case for quite a long > time. But it has nothing to do with Diffie-Hellman key exchanges... Aside from clarifying that we're assuming the use of X.509 certificates in the first place, this text is correct. I note that GnuTLS also works with OpenPGP keys, but I've never tested that here. Anyway, the current description is also accurate for GnuTLS. -- -- 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: add option for setting minimum TLS/SSL protocol (ITS#5655)
by guenther＠sendmail.com 19 Mar '09

19 Mar '09

On Fri, 23 Jan 2009, Howard Chu wrote: > guenther(a)sendmail.com wrote: > > I could have sworn I had uploaded the revised version of the patch back in > > August after some cleaning by Kurt, but have no way of confirming it. So > > I've uploaded it again as guenther-20081204.patch. > > Thanks, patch looks good, committed to HEAD. Have you got a manpage > update, by the way? Here's the chunk for ldap.conf(5), diffed against the trunk. None of the LDAP_OPT_X_TLS* options appear to be documented, so I didn't add anything to ldap_get_option(3). Philip Index: doc/man/man5/ldap.conf.5 =================================================================== RCS file: /data/cvs/openldap/pkg/ldap/doc/man/man5/ldap.conf.5,v retrieving revision 1.50 diff -u -r1.50 ldap.conf.5 --- doc/man/man5/ldap.conf.5 26 Jan 2009 01:54:32 -0000 1.50 +++ doc/man/man5/ldap.conf.5 19 Mar 2009 18:22:00 -0000 @@ -336,6 +336,19 @@ gnutls-cli -l .fi .TP +.B TLS_PROTOCOL_MIN <major>[.<minor>] +Specifies minimum SSL protocol version that will be negoiated. +If the server doesn't support at least that version, +the SSL handshake will fail. +To require TLS 1.x or higher, set this option to 3.(x+1), +e.g., +.B TLS_PROTOCOL_MIN 3.2 +would require TLS 1.1. +Specifying a minimum that is higher than that supported by the +OpenLDAP implementation will result it in requiring the +highest level that it does support. +This parameter is currently ignored with GNUtls. +.TP .B TLS_RANDFILE <filename> Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket.

1 0

Re: (ITS#5733) core dump in re24's slapd-ldap(5)
by quanah＠zimbra.com 18 Mar '09

18 Mar '09

--On Thursday, October 09, 2008 8:42 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: re24 > OS: Linux x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I had a strange core dump while testing re24 (test039). I'm reporting it > in order to be able to investigate it further later. Backtrace follows: I hit this today in testing RE24 as well: Thread 1 (process 27053): #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157 #4 0x00002b45fe1d4a34 in ldap_back_freeconn (li=0xba73080, lc=0x2aaab0003690, dolock=0) at ../../../../servers/slapd/back-ldap/bind.c:467 #5 0x00002b45fe1d6492 in ldap_back_release_conn_lock (li=0xba73080, lcp=0x45b9c5e8, dolock=1) at ../../../../servers/slapd/back-ldap/bind.c:1144 #6 0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../../servers/slapd/back-ldap/bind.c:355 #7 0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, which=op_bind, oi=0xba2cd90, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, which=op_bind) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/backover.c:731 #10 0x0000000000460681 in fe_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/bind.c:383 #11 0x00000000004c24da in overlay_op_walk (op=0xc168af0, rs=0x45b9cc40, which=op_bind, oi=0xba6def0, on=0x0) at ../../../servers/slapd/backover.c:669 #12 0x00000000004c26dd in over_op_func (op=0xc168af0, rs=0x45b9cc40, which=op_bind) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c272b in over_op_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/backover.c:731 #14 0x000000000045fdb0 in do_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../servers/slapd/bind.c:205 #15 0x0000000000438a70 in connection_operation (ctx=0x45b9cd90, arg_v=0xc168af0) at ../../../servers/slapd/connection.c:1097 #16 0x0000000000438f8b in connection_read_thread (ctx=0x45b9cd90, argv=0x17) at ../../../servers/slapd/connection.c:1223 #17 0x00002b45fad8b6b7 in ldap_int_thread_pool_wrapper (xpool=0xba14330) at ../../../libraries/libldap_r/tpool.c:663 #18 0x00002b45fb5442f7 in start_thread () from /lib64/libpthread.so.0 #19 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 (gdb) frame 6 #6 0x00002b45fe1d46b0 in ldap_back_bind (op=0xc168af0, rs=0x45b9cc40) at ../../../../servers/slapd/back-ldap/bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $1 = LDAP_BACK_RETRYING (gdb) frame 3 #3 0x00002b45fe1d3f51 in ldap_back_conn_delete (li=0xba73080, lc=0x2aaab0003690) at ../../../../servers/slapd/back-ldap/bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) print *lc $2 = {lc_conn = 0x2b45fea45f50, lc_ld = 0x2aaab00126d0, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 46, bv_val = 0x2aaaac126130 "cn=james a jones 4,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 46, bv_val = 0x2aaaac1192a0 "cn=james a jones 4,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $3 = 0x121 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5856) adauth overlay contribution
by hyc＠symas.com 18 Mar '09

18 Mar '09

neil.dunbar(a)hp.com wrote: > Still nothing? I can resubmit if the tarball has rotted away to nothing > on the incoming server. ;-) > > I don't mind if the code needs rewriting (it almost certainly does!), or > if it isn't felt to be the right fit for contrib, but a little feedback > would be helpful in getting things right. Sorry, we've been in bugfix-only mode for the past couple months. After this next (2.4.16) release is frozen we'll get back to working on new features. > > Cheers, > > Neil -- -- 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#5856) adauth overlay contribution
by neil.dunbar＠hp.com 18 Mar '09

18 Mar '09

Still nothing? I can resubmit if the tarball has rotted away to nothing on the incoming server. ;-) I don't mind if the code needs rewriting (it almost certainly does!), or if it isn't felt to be the right fit for contrib, but a little feedback would be helpful in getting things right. Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#6028) accesslog db after main db fails if main db is ""
by quanah＠zimbra.com 17 Mar '09

17 Mar '09

--On Tuesday, March 17, 2009 11:26 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.15 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > If the main database is rooted at "", and you go to create an accesslog > database to set up delta-syncrepl replication, the modification is > erroneously rejected by cn=config: bah, never mind. Still would be nice though. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6028) accesslog db after main db fails if main db is ""
by quanah＠zimbra.com 17 Mar '09

17 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If the main database is rooted at "", and you go to create an accesslog database to set up delta-syncrepl replication, the modification is erroneously rejected by cn=config: ERROR: Unable to add accesslog database to freelancer.lab.zimbra.com - exiting ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcSuffix> namingContext "cn=accesslog" already served by a preceding hdb database adding new entry "olcDatabase={3}hdb,cn=config" Inserting the accesslog DB in front of the existing database works as expected.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by hyc＠symas.com 17 Mar '09

17 Mar '09

martin.konold(a)erfrakon.de wrote: > Am Dienstag, 10. März 2009 06:53:34 schrieben Sie: > >> Please provide steps to reproduce the segfault, thanks. > > Hi Howard, > > I tried to reproduce the problem on either OpenSUSE 11.1 or Fedora but I could > not reproduce the crash. > > The crash was reproducable with OpenPKG though I guess the crash depends on > the version of bdb beeing used. The code fetches an transaction from an > internal table which might have slightly different semantics with regards to > initialization depending on bdb version. > > Anyway if you look at the rather trivial patch you will see that it indeed > solves a problem independent of bdb version used so the code does not depend > on a side effect anymore. > > On one hand the void pointer *data should not be dangeling and therefore > initialization with NULL is correct. *data will only be referenced if ldap_pvt_thread_pool_getkey() succeeds. If that function succeeds, data will have a value. There is no dangling pointer here. > On the other hand TXN_ABORT() must not be called with potentially dangeling > pointers and therefor a trivial check for the validitiy of the pointer is a > good idea. Likewise, bdb_reader_free() will only get called as a result of successful pool_setkey() calls. There will be no dangling pointers there either. Since most of this code has been in place since 2002 and no one else has reported the problem before, it seems to me that OpenPKG is doing something very unusual. And being unable to reproduce the problem ourselves, I'd like to see exactly what they're doing to cause it. I've committed part of the patch in the meantime, but until we see steps to reproduce the crash, I'm unconvinced that this is any meaningful change. -- -- 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: [Fwd: RE: (ITS#6019) puzon@eska.pl]
by hyc＠symas.com 17 Mar '09

17 Mar '09

This appears to be a dup of ITS#6014. Closing this one, send all future followups to #6014. michael(a)stroeder.com wrote: > The stack trace was sent to me personally. :-/ > > -------- Original Message -------- > Subject: RE: (ITS#6019) puzon(a)eska.pl > Date: Fri, 13 Mar 2009 15:09:04 +0100 > From: Lukasz PUZON Brodowski<puzon(a)eska.pl> > To: 'Michael Ströder'<michael(a)stroeder.com> > References:<200903121120.n2CBKHqo032649(a)boole.openldap.org> > <49B90F15.5070309(a)stroeder.com> > > Hi Michael > > Here is gdb: > (15:07:44<~>) 0 # gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > (gdb) file ldapsearch > Reading symbols from ldapsearch...(no debugging symbols found)...done. > (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base > Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b > "" -s base > (no debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)...Enter LDAP > Password: > # extended LDIF > # > # LDAPv3 > # base<> with scope baseObject > # filter: (objectclass=*) > # requesting: ALL > # > > # > dn: > objectClass: top > objectClass: OpenLDAProotDSE > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > Program received signal SIGSEGV, Segmentation fault. > 0x282eb3f0 in free () from /lib/libc.so.7 > > > -- -- 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#6025) ldapdelete cannot handle base64 encoded dns
by hyc＠symas.com 17 Mar '09

17 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24/HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334354 the OpenLDAP > ldapdelete utility cannot handle base-64 encoded DNs, even though the other > ldap* tools can. It would add to the tool consistency for ldapdelete to conform > with the other tools in this respect. Why are you bothering to report this now, when the original bug was filed in 2005 and went unanswered until last month? I agree with Peter Marschall's response - this is not a bug, and your assertion "other ldap* tools can" is false. ldapdelete is documented to take a list of DNs. It does *NOT* say that it takes them in LDIF format, and LDIF is the only relevant format specification that uses base64. As such, "DN" should only be taken to mean RFC4514 compliant strings. The only tool that accepts LDIF is ldapmodify (and ldapadd is just a symlink to ldapmodify). All of the other tools are specifically documented to take DNs, not LDIF. This ITS will be closed. -- -- 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#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 17 Mar '09

17 Mar '09

> I did my best to reproduce your setup, but I got no crashes. One > thing I'd like to ask is: I see some non-standard attributes in the > pcache configuration. Can you tell whether there might occur some > schema inconsistencies between the remote server and the proxy? No, they're the same - the schema files are distributed via RPM and configured in slapd.conf with the same bit of configuration code. > Also, can you tell how often crashes occur, or any detail about the > type of operation, the workload and so? The machines I'm currently testing with are all in a student lab, running condor jobs when quiet, so a bit difficult to predict - I haven't seen any discernible pattern so far - I've seen crashes on busy machines and quiet ones. For the core file we're looking at here, this machine had answered 9 queries in the second prior to the crash, but had been quiet for 3 minutes prior to that after it had removed stale entries from the cache. I can attach a portion of the slapd log if it would be useful. As for how often the crashes occur, these 24 lab machines have been running 2.4.15 built with no optimisation since 27th Feb and have produced 18 core files in that time. Of these, approximately half have been assertion failures for free(p) in memory.c:152. I've seen 3 cases of segfaults in pcache_filter_cmp, as mentioned in ITS#5756, but I'll submit non-optimised backtraces to that ticket, rather than confuse the issue here. > I also disabled slab allocation, so that true mallocs occur all > times, and valgrind is not showing any memory issue. The difficulty is in trying to reproduce this - my own desktop machine is running with the same setup and has never crashed, despite my best efforts. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by hyc＠symas.com 17 Mar '09

17 Mar '09

ando(a)sys-net.it wrote: > test.007(a)seznam.cz wrote: >> Full_Name: Test Seven >> Version: 2.4.15 >> OS: Windows >> URL: >> Submission from: (NULL) (195.39.55.20) > > Fixed in HEAD, please test. Thanks, p. The fix looks fine, but I was unable to reproduce the original error. It seems their build is broken. -- -- 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#6027) Debug() accesses free()-d memory in register_at() on error
by ando＠sys-net.it 17 Mar '09

17 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) Fixed in HEAD, please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 17 Mar '09

17 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.39.55.20) http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/at.c?rev=… ldap_attributetype_free( at ); Debug( LDAP_DEBUG_ANY, "register_at: AttributeType \"%s\": %s, %s\n", def, scherr2str(code), err ); You should swap the lines, because ``err'' points inside ``at''. How to reproduce: Compile Debug version with LDAP_DEBUG e.g. with MSVC 2005. Don't configure it slapd.exe -d9 Output: register_at: AttributeType "( OLcfgDbAt:0.1 NAME 'olcDbDirectory' DESC 'Director y for database content' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGL E-VALUE )": OID could not be expanded, ŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢ

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 16 Mar '09

16 Mar '09

I tested it again and found that there is not memory leak on gcc 4.1.2 and openssl 0.9.8c. The leak version is on gcc 3.3.5 and OpenSSL 0.9.7d. So, it may be not a bug of openLDAP but the other old version software.

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by ando＠sys-net.it 16 Mar '09

16 Mar '09

toby(a)inf.ed.ac.uk wrote: > On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: > > Hello, > > Thanks for your quick reply. > >>> (gdb) bt >>> #0 0x00b8d402 in __kernel_vsyscall () >>> #1 0x009e8d20 in raise () from /lib/libc.so.6 >>> #2 0x009ea631 in abort () from /lib/libc.so.6 >>> #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 >>> #4 0x00a28b16 in _int_free () from /lib/libc.so.6 >>> #5 0x00a2c070 in free () from /lib/libc.so.6 >>> #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c: >>> 152 >>> #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at >>> memory.c:731 >>> #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 >>> #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 >> The problem seems to be here; apparently, the a->a_nvals array is >> being incorrectly freed. If you have those core files around, it >> would be interesting to see the contents of those attributes, e.g. >> >> p *a >> p a->a_desc[0] >> p a->a_flags >> p a->a_nvals[0] >> >> from within frame 9. > > > (gdb) up > #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 > 134 ber_bvarray_free( a->a_nvals ); > (gdb) p *a > $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, > a_numvals = 631, a_flags = 0, a_next = 0x0} > (gdb) p a->a_desc[0] > $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, > bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = > 0x0}, > ad_flags = 0} > (gdb) p a->a_flags > $3 = 0 > (gdb) p a->a_nvals[0] > $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} > (gdb) > > >>> #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 >>> #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 >>> #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) >>> at search.c:354 >> Also, it would be interesting to see the parameters of the search; >> e.g. >> >> p op->o_req_ndn >> p op->o_request.oq_search >> p op->o_request.oq_search.rs_filterstr >> p op->o_request.oq_search.rs_attrs[0] (unless NULL) >> >> from within frame 12 > > > (gdb) up > #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) > at search.c:354 > 354 entry_clean( &ent ); > (gdb) p op->o_req_ndn > $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} > (gdb) p op->o_request.oq_search > $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, > rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, > rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} > (gdb) p op->o_request.oq_search.rs_filterstr > $7 = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} > (gdb) p op->o_request.oq_search.rs_attrs[0] > $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, > an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} > (gdb) > > >> Finally, it would be great to see your slapd.conf. > > > No problem, this is the database, back-ldap, pcache part of it: > > database ldap > suffix dc=inf,dc=ed,dc=ac,dc=uk > rootdn uid=ldaprep/ > hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth > uri "ldap://server1.inf.ed.ac.uk/,ldap:// > server2.inf.ed.ac.uk" > idassert-bind mode=none > bindmethod=sasl > saslmech=GSSAPI > idassert-authzFrom "dn:*" > > overlay pcache > > proxycache bdb 5000 4 500 300 > proxycachequeries 10000 > > proxyattrset 0 cn userPassword memberUid uniqueMember > gidNumber > proxyattrset 1 uid userPassword uidNumber gidNumber cn > homeDirectory > loginShell gecos description objectClass afsHomeDirectory primaryRoles > secondary > Roles > proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup > proxyattrset 3 "*" > > proxytemplate (uid=) 1 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 > proxytemplate (&(objectClass=)(|(memberUid=) > (uniqueMember=))) 0 1800 1800 > proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 > proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 > proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 > proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 > proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 > 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 > > directory /var/openldap-data > > checkpoint 128 60 > cachesize 10000 > idlcachesize 10000 > > dbconfig set_cachesize 0 16777216 1 > dbconfig set_lg_regionmax 262144 > dbconfig set_lg_bsize 2097152 > > > If there's anything else that would be useful, let me know. As I > mentioned, I have a number of other core files, including some that > look the same as this one. I did my best to reproduce your setup, but I got no crashes. One thing I'd like to ask is: I see some non-standard attributes in the pcache configuration. Can you tell whether there might occur some schema inconsistencies between the remote server and the proxy? Also, can you tell how often crashes occur, or any detail about the type of operation, the workload and so? I also disabled slab allocation, so that true mallocs occur all times, and valgrind is not showing any memory issue. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 16 Mar '09

16 Mar '09

On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: Hello, Thanks for your quick reply. >> (gdb) bt >> #0 0x00b8d402 in __kernel_vsyscall () >> #1 0x009e8d20 in raise () from /lib/libc.so.6 >> #2 0x009ea631 in abort () from /lib/libc.so.6 >> #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 >> #4 0x00a28b16 in _int_free () from /lib/libc.so.6 >> #5 0x00a2c070 in free () from /lib/libc.so.6 >> #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c: >> 152 >> #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at >> memory.c:731 >> #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 >> #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 > > The problem seems to be here; apparently, the a->a_nvals array is > being incorrectly freed. If you have those core files around, it > would be interesting to see the contents of those attributes, e.g. > > p *a > p a->a_desc[0] > p a->a_flags > p a->a_nvals[0] > > from within frame 9. (gdb) up #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 134 ber_bvarray_free( a->a_nvals ); (gdb) p *a $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, a_numvals = 631, a_flags = 0, a_next = 0x0} (gdb) p a->a_desc[0] $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p a->a_flags $3 = 0 (gdb) p a->a_nvals[0] $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} (gdb) >> #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 >> #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 >> #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) >> at search.c:354 > > Also, it would be interesting to see the parameters of the search; > e.g. > > p op->o_req_ndn > p op->o_request.oq_search > p op->o_request.oq_search.rs_filterstr > p op->o_request.oq_search.rs_attrs[0] (unless NULL) > > from within frame 12 (gdb) up #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 354 entry_clean( &ent ); (gdb) p op->o_req_ndn $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} (gdb) p op->o_request.oq_search $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} (gdb) p op->o_request.oq_search.rs_filterstr $7 = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} (gdb) p op->o_request.oq_search.rs_attrs[0] $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} (gdb) > Finally, it would be great to see your slapd.conf. No problem, this is the database, back-ldap, pcache part of it: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/ hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://server1.inf.ed.ac.uk/,ldap:// server2.inf.ed.ac.uk" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 4 500 300 proxycachequeries 10000 proxyattrset 0 cn userPassword memberUid uniqueMember gidNumber proxyattrset 1 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup proxyattrset 3 "*" proxytemplate (uid=) 1 1800 1800 proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=) (uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 1800 1800 proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 directory /var/openldap-data checkpoint 128 60 cachesize 10000 idlcachesize 10000 dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 If there's anything else that would be useful, let me know. As I mentioned, I have a number of other core files, including some that look the same as this one. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

ITS#6019
by puzon＠eska.pl 16 Mar '09

16 Mar '09

(15:07:44 <~>) 0 # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". (gdb) file ldapsearch Reading symbols from ldapsearch...(no debugging symbols found)...done. (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b "" -s base (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Program received signal SIGSEGV, Segmentation fault. 0x282eb3f0 in free () from /lib/libc.so.7

1 0

(ITS#6026) Don't run autosaved test scripts
by rein＠OpenLDAP.org 16 Mar '09

16 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When running the entire test suite it happily includes autosaved versions of the test scripts. Which can be a bit annoying if the scripts are edited with an editor that loves to leave autosave files around.. A fix is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 16 Mar '09

16 Mar '09

As you methioned, I move ldap_set_option() with NULL to the main thread. And, I also use libldap_r instead of libldap. A specific handler is really only used in a single thread. In every thread, it always returns NULL, because it is just a test code and it always print "connect ok" while it is running. I think memory leak may happen when the code of openLDAP uses openssl function such as initialize connection in ldap_start_tls_s(). For every thread, there may be some special structures for SSL/TLS which need to be freed after the end of the thread. I find that Windows has a function ldap_stop_tls_s() related to ldap_start_tls_s(). For my software, I want to create processes instead of threads to avoid this problem.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs