- openldap-bugs - openldap.org

(ITS#6011) test050 segfault
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/9/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Current RE24 segfaults in test050 for me. Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 (gdb) thr apply all bt Thread 7 (process 5559): #0 0x00002b457abc55b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b457a40cb2b in ldap_pvt_thread_join (thread=1088002368, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000435dbf in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418104 in main (argc=8, argv=0x7fff306aeb18) at ../../../servers/slapd/main.c:948 Thread 6 (process 5574): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435071 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (process 5589): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b457a660bce in ber_error_print (data=0x4171d920 "ber_scanf fmt ({mW}) ber:\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b457a660edb in ber_pvt_log_printf (errlvl=1, loglvl=261, fmt=0x2b457a664bee "ber_scanf fmt (%s) ber:\n") at ../../../libraries/liblber/bprint.c:141 #5 0x00002b457a65be36 in ber_scanf (ber=0xde6fee0, fmt=0x516949 "{mW}") at ../../../libraries/liblber/decode.c:784 #6 0x00000000004b3434 in syncrepl_message_to_entry (si=0x2aaaac0195e0, op=0x4171e690, msg=0xde63100, modlist=0x4171e418, entry=0x4171e4e0, syncstate=1) at ../../../servers/slapd/syncrepl.c:1855 #7 0x00000000004afbe0 in do_syncrep2 (op=0x4171e690, si=0x2aaaac0195e0) at ../../../servers/slapd/syncrepl.c:887 #8 0x00000000004b1546 in do_syncrepl (ctx=0x4171ed90, arg=0x2aaaac016d00) at ../../../servers/slapd/syncrepl.c:1348 #9 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #10 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #11 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (process 5590): #0 0x00000000004c3ed3 in slap_compose_sync_cookie (op=0x0, cookie=0x2aaaac017640, csn=0x0, rid=1, sid=2) at ../../../servers/slapd/ldapsync.c:47 #1 0x00000000004aefcc in do_syncrep1 (op=0x42438690, si=0x2aaaac017480) at ../../../servers/slapd/syncrepl.c:661 #2 0x00000000004b14b4 in do_syncrepl (ctx=0x42438d90, arg=0x2aaaac0182b0) at ../../../servers/slapd/syncrepl.c:1336 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (process 5615): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 #3 0x00002b457a660c18 in ber_error_print (data=0x42c38850 "<= ldap_bv2dn(cn=config)=0 \n") at ../../../libraries/liblber/bprint.c:87 #4 0x00002b457a433465 in ldap_log_printf (ld=0x0, loglvl=4, fmt=0x2b457a447b90 "<= ldap_bv2dn(%s)=%d %s\n") at print.c:60 #5 0x00002b457a4201fc in ldap_bv2dn_x (bvin=0x2aaab000b1b0, dn=0x42c38f50, flags=0, ctx=0x0) at getdn.c:892 #6 0x0000000000453ccb in dnNormalize (use=2, syntax=0xd810b10, mr=0xd815030, val=0x2aaab000b1b0, out=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/dn.c:438 #7 0x000000000045e7e4 in ordered_value_normalize (usage=2, ad=0xd81c310, mr=0xd815030, val=0x2aaab000b1b0, normalized=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/value.c:583 #8 0x0000000000458cf3 in slap_mods_check (op=0x42c39630, ml=0x2aaab000b200, text=0x42c39238, textbuf=0x42c39130 "p\221�B", textlen=256, ctx=0x0) at ../../../servers/slapd/modify.c:625 #9 0x00000000004b35c8 in syncrepl_message_to_entry (si=0x2aaaac0177a0, op=0x42c39630, msg=0x2aaab000afa0, modlist=0x42c393b8, entry=0x42c39480, syncstate=1) at ../../../servers/slapd/syncrepl.c:1892 #10 0x00000000004afbe0 in do_syncrep2 (op=0x42c39630, si=0x2aaaac0177a0) at ../../../servers/slapd/syncrepl.c:887 #11 0x00000000004b1546 in do_syncrepl (ctx=0x42c39d90, arg=0x2aaaac00db90) at ../../../servers/slapd/syncrepl.c:1348 #12 0x0000000000439047 in connection_read_thread (ctx=0x42c39d90, argv=0x9) at ../../../servers/slapd/connection.c:1225 #13 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #14 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #15 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (process 5767): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b457a40cb53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x43c3bd90, arg=0xdc43fc0) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (process 5616): #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 #1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 #2 0x00002aaaaaab9799 in syncprov_op_response (op=0x4343a630, rs=0x4343a1b0) at ../../../../servers/slapd/overlays/syncprov.c:1673 #3 0x000000000044e039 in slap_response_play (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:349 #4 0x000000000044e24f in send_ldap_response (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:423 #5 0x000000000044f101 in slap_send_ldap_result (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:692 #6 0x00000000004272f3 in config_back_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/bconfig.c:5197 #7 0x00000000004c206a in overlay_op_walk (op=0x4343a630, rs=0x4343a1b0, which=op_modify, oi=0xda30020, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c226d in over_op_func (op=0x4343a630, rs=0x4343a1b0, which=op_modify) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c234b in over_op_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/backover.c:755 #10 0x00000000004b7209 in syncrepl_updateCookie (si=0xdc44440, op=0x4343a630, pdn=0xd83fd20, syncCookie=0x4343a420) at ../../../servers/slapd/syncrepl.c:2979 #11 0x00000000004afc79 in do_syncrep2 (op=0x4343a630, si=0xdc44440) at ../../../servers/slapd/syncrepl.c:894 #12 0x00000000004b1546 in do_syncrepl (ctx=0x4343ad90, arg=0xdc44850) at ../../../servers/slapd/syncrepl.c:1348 #13 0x0000000000439047 in connection_read_thread (ctx=0x4343ad90, argv=0xe) at ../../../servers/slapd/connection.c:1225 #14 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #15 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #16 0x000000395e0d1e3d in clone () from /lib64/libc.so.6

1 0

ldapsearch weird results - wild card not working as expected
by Simon McGregor 09 Mar '09

09 Mar '09

I wrote a script to add groups to my ldap directory --------------------------------- #!/bin/sh # Get the latest gid gidlast="`ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1`" newgid="`echo "$gidlast + 1" | bc`" echo "newgid: $newgid" # Make the Mods echo "dn: cn=$1,ou=Group,dc=mydomain,dc=com" > /tmp/modify.ldap echo "changetype: add" >> /tmp/modify.ldap echo "objectClass: posixGroup" >> /tmp/modify.ldap echo "objectClass: top" >> /tmp/modify.ldap echo "cn: $1" >> /tmp/modify.ldap echo "gidNumber: $newgid" >> /tmp/modify.ldap # Run the Update ldapmodify -x -f /tmp/modify.ldap -h myserver -D cn=Manager,dc=mydomain,dc=com -w mypasswd ---------------------------------- This correctly creates a new group eg. ./mkgroup.sh mygroup01 $ ldapsearch -x "cn=mygroup01" -h myserver produces -> # mygroup01, Group, mydomain.com dn: cn=mygroup01,ou=Group,dc=mydomain,dc=com objectClass: posixGroup objectClass: top cn: mygroup01 gidNumber: 7435 memberUid: dummyuser The issue is the following: $ ldapsearch -x "cn=mygroup*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7435 $ ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7434 In other words the wild card is not picking up the new group even though it is actually there. Perhaps someone can show me the error of my ways but I think both results should return the same value I am running centos 5 with openldap-clients-2.3.27-8.el5_2.4 openldap-servers-2.3.27-8.el5_2.4 openldap-2.3.27-8.el5_2.4 openldap-devel-2.3.27-8.el5_2.4 The information contained in this email and any attachments is strictly confidential. If you are not the intended recipient you must not disclose or use the information contained in it. If you have received this email in error please notify us immediately by return email and delete the document. Domain Principal Pty Ltd accepts no liability for any loss or damage caused by this email or its attachments due to viruses interference interception corruption or unauthorised access.

2 1

Re: (ITS#6010) substitution for acl sets
by hyc＠symas.com 09 Mar '09

09 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, > the man page is lacking documentation on this feature. It should be added. The man page lacks documentation on sets, period... The examples in the Admin Guide only touch on one use case. I think it's time we acknowledged that this feature exists, largely unchanged from its initial inception. (Yes, features have been added, but there's been no radical redesign.) -- -- 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#6004) test039 seg faults
by hyc＠symas.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >>> tar.gz >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Hallvard's situation was mainly due to his particular -rpath requirements. The libtool wrapper script will set LD_LIBRARY_PATH to include all of the build directories of its dependent libraries, but that didn't help because of his compiled in runpaths. -- -- 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#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > >> Quanah Gibson-Mount wrote: >>> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >>> >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Str?der >>>>> Version: HEAD >>>>> OS: openSUSE Linux 11.1 >>>>> URL: >>>>> Submission from: (NULL) (84.163.90.131) >>>>> >>>>> Will try to grab a stack trace. >>>> >>>> So here's the end of the output of test039 (with HDB) and a backtrace. >>>> >>>> See also a tar.gz of directory testrun/: >>>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>>> s. tar.gz >>> >>> Why are the symbols missing from most of the stack frames? The build >>> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >>> causing it to pick up some other libraries on the system that are >>> stripped? >> >> Hmm, a pre-installed libldap could be picked up if -releng is already >> removed from the shared lib names. Since this is switched back and forth >> in CVS there's no easy way to keep my system working and maintain a >> completely separate build tree. That's an issue Hallvard already raised >> (with no success). > > Current RE24 is releng, so if your CVS tree is fully up to date, it > should not pick up any other ldap libs. Sorry, I had the RE24 local installation in the LD_LIBRARY_PATH. Hmm... Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>> s. tar.gz >> >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are >> stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Current RE24 is releng, so if your CVS tree is fully up to date, it should not pick up any other ldap libs. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.90.131) >>> >>> Will try to grab a stack trace. >> >> So here's the end of the output of test039 (with HDB) and a backtrace. >> >> See also a tar.gz of directory testrun/: >> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >> tar.gz > > Why are the symbols missing from most of the stack frames? The build > should always have symbols. Do you have an LD_LIBRARY_PATH set that's > causing it to pick up some other libraries on the system that are stripped? Hmm, a pre-installed libldap could be picked up if -releng is already removed from the shared lib names. Since this is switched back and forth in CVS there's no easy way to keep my system working and maintain a completely separate build tree. That's an issue Hallvard already raised (with no success). Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.90.131) >> >> Will try to grab a stack trace. > > So here's the end of the output of test039 (with HDB) and a backtrace. > > See also a tar.gz of directory testrun/: > http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. > tar.gz Why are the symbols missing from most of the stack frames? The build should always have symbols. Do you have an LD_LIBRARY_PATH set that's causing it to pick up some other libraries on the system that are stripped? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6010) substitution for acl sets
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, the man page is lacking documentation on this feature. It should be added.

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

Yeah, I know. ;) But there's a few fixes left to go in, including what I believe will fix what you saw. That's why I haven't called for testing yet on openldap-devel. --Quanah --On Monday, March 09, 2009 6:30 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: RE24 >>> >>> Seems to work in HEAD on the very same system. >> >> RE24 is not ready for testing yet. > > Well, Howard recently recommended to use it (see below). So I'm testing > as usual... > > Ciao, Michael. > > -------- Original Message -------- > Subject: Re: RE24 (2.4.15) slapd consuming large amounts of CPU > Date: Sat, 07 Mar 2009 00:47:57 -0800 > From: Howard Chu <hyc(a)symas.com> > To: John Morrissey <jwm(a)horde.net> > CC: openldap-software(a)openldap.org > References: <20090304185521.GA3184(a)boost.horde.net> > <49AEE757.3000502(a)symas.com> <20090306141020.GA7876(a)boost.horde.net> > > John Morrissey wrote: >> On Wed, Mar 04, 2009 at 12:40:55PM -0800, Howard Chu wrote: >>> John Morrissey wrote: >>>> A backtrace (below) shows many threads waiting on a mutex in >>>> bdb_cache_*(). >>> From the trace it looks similar to ITS#5860. The patches for this >>> are in HEAD, not yet released. >> >> With an shm_key, slapd CPU consumption dropped noticably and has been >> running long enough to make the leak apparent. >> >> Since this second-round fix for ITS#5860 has been merged into RE24, >> do you recommend running that, or should I cherry-pick >> 1.120.2.{21,22} into our local packaging? > > At this point I would just use RE24. Unless any new critical bugs show > up in the next few days, it's very likely what will be 2.4.16. > > -- > -- 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#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: > >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: RE24 >> >> Seems to work in HEAD on the very same system. > > RE24 is not ready for testing yet. Well, Howard recently recommended to use it (see below). So I'm testing as usual... Ciao, Michael. -------- Original Message -------- Subject: Re: RE24 (2.4.15) slapd consuming large amounts of CPU Date: Sat, 07 Mar 2009 00:47:57 -0800 From: Howard Chu <hyc(a)symas.com> To: John Morrissey <jwm(a)horde.net> CC: openldap-software(a)openldap.org References: <20090304185521.GA3184(a)boost.horde.net> <49AEE757.3000502(a)symas.com> <20090306141020.GA7876(a)boost.horde.net> John Morrissey wrote: > On Wed, Mar 04, 2009 at 12:40:55PM -0800, Howard Chu wrote: >> John Morrissey wrote: >>> A backtrace (below) shows many threads waiting on a mutex in >>> bdb_cache_*(). >> From the trace it looks similar to ITS#5860. The patches for this >> are in HEAD, not yet released. > > With an shm_key, slapd CPU consumption dropped noticably and has been > running long enough to make the leak apparent. > > Since this second-round fix for ITS#5860 has been merged into RE24, > do you recommend running that, or should I cherry-pick > 1.120.2.{21,22} into our local packaging? At this point I would just use RE24. Unless any new critical bugs show up in the next few days, it's very likely what will be 2.4.16. -- -- 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#6009) test019: test failed - master and R2 slave databases differ
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str?der >> Version: RE24 > > Seems to work in HEAD on the very same system. RE24 is not ready for testing yet. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> P.S.: I had this case more than once: A test script exited with error >> when being run within 'make test' but then I can't reproduce the issue. > > Yeah, that's the nature of things. We should probably add a "ulimit -c > unlimited" to the run script so we can always get a core file. Already added this to my build script which also invokes 'make test'. > Problems of this type that occur during "make test" but not when > running the individual script seem to have a dependency on the memory > pressure from other processes. (I.e., when "make test" is running > there are more processes than when you simply run an individual > script.) Well, I thought running OpenOffice, Seamonkey and an additional virtual machine on my ancient 1 GB laptop is enough "memory pressure". But it seems to happen rarely. > In this case, it's most likely ITS#5733, which still hasn't been tracked > down. Anyway I was able to obtain a stack-trace. See my other posting. Ciao, Michael.

1 0

Re: (ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 09 Mar '09

09 Mar '09

--0016364edc12a6fc2e0464b21737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=XXXX,dc=com" credentials=secret mode=self starttls=yes tls_reqcert=never chain-tls start chain-return-error TRUE ----------- bind as rootdn ---------------------- conn=7 fd=14 ACCEPT from IP=10.1.1.10:42992 (IP=0.0.0.0:389) conn=7 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=7 op=0 STARTTLS conn=7 op=0 RESULT oid= err=0 text= conn=7 fd=14 TLS established tls_ssf=256 ssf=256 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" method=128 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=7 op=1 RESULT tag=97 err=0 text= conn=7 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=7 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=7 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=7 op=3 MOD attr=userPassword userPassword TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. conn=7 op=3 RESULT tag=103 err=52 text= conn=7 op=4 UNBIND conn=7 fd=14 closed ----------- bind as normal user ---------------------- conn=11 fd=14 ACCEPT from IP=10.1.1.10:36765 (IP=0.0.0.0:389) conn=11 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=11 op=0 STARTTLS conn=11 op=0 RESULT oid= err=0 text= conn=11 fd=14 TLS established tls_ssf=256 ssf=256 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=11 op=1 RESULT tag=97 err=0 text= conn=11 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=11 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=11 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=11 op=3 MOD attr=userPassword userPassword conn=11 op=3 RESULT tag=103 err=0 text= conn=11 op=4 UNBIND conn=11 fd=14 closed conn=12 fd=14 ACCEPT from IP=10.1.1.10:36766 (IP=0.0.0.0:389) conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=12 op=0 STARTTLS conn=12 op=0 RESULT oid= err=0 text= conn=12 fd=14 TLS established tls_ssf=256 ssf=256 conn=12 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=12 op=1 RESULT tag=97 err=49 text= conn=13 fd=24 ACCEPT from IP=10.1.1.10:36767 (IP=0.0.0.0:389) conn=13 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=13 op=0 STARTTLS conn=13 op=0 RESULT oid= err=0 text= conn=13 fd=24 TLS established tls_ssf=256 ssf=256 conn=13 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=13 op=1 RESULT tag=97 err=49 text= conn=12 op=2 UNBIND conn=12 fd=14 closed conn=13 op=2 UNBIND conn=13 fd=24 closed --0016364edc12a6fc2e0464b21737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX c= hain-rebind-as-user TRUE chain-idassert-bind =A0=A0=A0 bindmethod=3Ds= imple =A0=A0=A0 binddn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" = =A0=A0=A0 credentials=3Dsecret =A0=A0=A0 mode=3Dself =A0=A0=A0 starttls=3Dyes =A0=A0=A0 tls_reqcert= =3Dnever chain-tls start chain-return-error TRUE ----------- b= ind as rootdn ---------------------- conn=3D7 fd=3D14 ACCEPT from IP= =3D<a href=3D"http://10.1.1.10:42992">10.1.1.10:42992</a> (IP=3D<a href=3D"= http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D7 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D7 op=3D0 STARTTL= S conn=3D7 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D7 fd=3D14 TLS = established tls_ssf=3D256 ssf=3D256 conn=3D7 op=3D1 BIND dn=3D"cn= =3DManager,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D7 op=3D1 BIND dn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" mech= =3DSIMPLE ssf=3D0 conn=3D7 op=3D1 RESULT tag=3D97 err=3D0 text=3D con= n=3D7 op=3D2 SRCH base=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dco= m" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)" conn=3D7 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D con= n=3D7 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom&q= uot; conn=3D7 op=3D3 MOD attr=3DuserPassword userPassword TLS certifi= cate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CER= TIFICATE:certificate verify failed. conn=3D7 op=3D3 RESULT tag=3D103 err= =3D52 text=3D conn=3D7 op=3D4 UNBIND conn=3D7 fd=3D14 closed <= br>----------- bind as normal user ---------------------- conn=3D11 fd=3D14 ACCEPT from IP=3D<a href=3D"http://10.1.1.10:36765">1= 0.1.1.10:36765</a> (IP=3D<a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>)<br= >conn=3D11 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D11 op=3D0 STAR= TTLS conn=3D11 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D11 fd=3D14 TLS established tls_ssf=3D256 ssf=3D256 conn=3D11 op= =3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" me= thod=3D128 conn=3D11 op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,d= c=3DXXXX,dc=3Dcom" mech=3DSIMPLE ssf=3D0 conn=3D11 op=3D1 RESULT tag=3D97 err=3D0 text=3D conn=3D11 op=3D2 SRCH b= ase=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" scope=3D0 d= eref=3D0 filter=3D"(objectClass=3D*)" conn=3D11 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D11 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dc= om" conn=3D11 op=3D3 MOD attr=3DuserPassword userPassword conn= =3D11 op=3D3 RESULT tag=3D103 err=3D0 text=3D conn=3D11 op=3D4 UNBIND<br= >conn=3D11 fd=3D14 closed conn=3D12 fd=3D14 ACCEPT from IP=3D<a href=3D"= http://10.1.1.10:36766">10.1.1.10:36766</a> (IP=3D<a href=3D"http://0.0.0.0= :389">0.0.0.0:389</a>) conn=3D12 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D12 op=3D0 START= TLS conn=3D12 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D12 fd=3D14 = TLS established tls_ssf=3D256 ssf=3D256 conn=3D12 op=3D1 BIND dn=3D&quot= ;uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D12 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D13 fd=3D24 ACCE= PT from IP=3D<a href=3D"http://10.1.1.10:36767">10.1.1.10:36767</a> (IP=3D<= a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D13 op=3D0 EXT oid= =3D1.3.6.1.4.1.1466.20037 conn=3D13 op=3D0 STARTTLS conn=3D13 op=3D0 RESULT oid=3D err=3D0 text=3D= conn=3D13 fd=3D24 TLS established tls_ssf=3D256 ssf=3D256 conn=3D13 = op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" = method=3D128 conn=3D13 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D12 op=3D2 UNBIND conn=3D12 fd=3D14 closed conn=3D13 op=3D2 UNB= IND conn=3D13 fd=3D24 closed --0016364edc12a6fc2e0464b21737--

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.90.131) > > Will try to grab a stack trace. So here's the end of the output of test039 (with HDB) and a backtrace. See also a tar.gz of directory testrun/: http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults.ta… Ciao, Michael. ----------------------------- snip ----------------------------- PID=12116 - Read(1000): entry="cn=Database 1,cn=Databases,cn=Monitor". PID=12113 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=12119 - Bind(1000): dn="". PID=12125 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Barbara Jensen)" attrs=cn (more...). slapd-search PID=12113: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" slapd-read PID=12116: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=12119: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=12119 - Bind done (-1). slapd-search PID=12125: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=12133 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=12142 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-read PID=12133: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=12142: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=12142 - Bind done (-1). PID=12156 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). slapd-search PID=12156: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" stopping: child exited with status 1 ./scripts/test039-glue-ldap-concurrency: line 188: 11492 Aborted (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 slapd-tester failed (1)! ./scripts/test039-glue-ldap-concurrency: line 193: kill: (11492) - No such process >>>>> ./scripts/test039-glue-ldap-concurrency failed (exit 1) make[2]: *** [hdb-yes] Error 1 ----------------------------- snip ----------------------------- (gdb) info threads 18 Thread 11817 0x40070f0d in ber_printf (ber=0x454c4c74, fmt=0x81c654c "{O{") at encode.c:855 17 Thread 11522 0xffffe430 in __kernel_vsyscall () 16 Thread 11754 0xffffe430 in __kernel_vsyscall () 15 Thread 11815 0xffffe430 in __kernel_vsyscall () 14 Thread 11739 0xffffe430 in __kernel_vsyscall () 13 Thread 11507 0xffffe430 in __kernel_vsyscall () 12 Thread 11781 0xffffe430 in __kernel_vsyscall () 11 Thread 11782 0xffffe430 in __kernel_vsyscall () 10 Thread 11749 0xffffe430 in __kernel_vsyscall () 9 Thread 11813 0xffffe430 in __kernel_vsyscall () 8 Thread 11697 0xffffe430 in __kernel_vsyscall () 7 Thread 11821 0xffffe430 in __kernel_vsyscall () 6 Thread 11717 0xffffe430 in __kernel_vsyscall () 5 Thread 11719 0xffffe430 in __kernel_vsyscall () 4 Thread 11703 0xffffe430 in __kernel_vsyscall () 3 Thread 11492 0xffffe430 in __kernel_vsyscall () 2 Thread 11660 0xffffe430 in __kernel_vsyscall () * 1 Thread 11679 0xffffe430 in __kernel_vsyscall () (gdb) thread apply all bt Thread 18 (Thread 11817): #0 0x40070f0d in ber_printf (ber=0x454c4c74, fmt=0x81c654c "{O{") at encode.c:855 #1 0x0807b5f8 in ?? () #2 0x0810da3a in ?? () #3 0x0810d94c in ?? () #4 0x0810dd5d in ?? () #5 0x0806bcf3 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0806c568 in ?? () #9 0x0806983b in ?? () #10 0x0806a297 in ?? () #11 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x83ee578) at tpool.c:663 #12 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #13 0x405793be in clone () from /lib/libc.so.6 Thread 17 (Thread 11522): #0 0xffffe430 in __kernel_vsyscall () #1 0x40250b3b in write () from /lib/libpthread.so.0 #2 0x4007547b in sb_stream_write (sbiod=0x45c12248, buf=0x40fad17c, len=65) at sockbuf.c:535 #3 0x400745ba in sb_debug_write (sbiod=0x45c10310, buf=0x40fad17c, len=65) at sockbuf.c:852 #4 0x400749c2 in ber_int_sb_write (sb=0x45c0e490, buf=0x40fad17c, len=65) at sockbuf.c:445 #5 0x40072244 in ber_flush2 (sb=0x45c0e490, ber=0x40fa9c74, freeit=0) at io.c:256 #6 0x0807a49f in ?? () #7 0x0807c5bb in ?? () #8 0x0810da3a in ?? () #9 0x0810d94c in ?? () #10 0x0810dd5d in ?? () #11 0x0806bcf3 in ?? () #12 0x080d2f0c in ?? () #13 0x080d3ad4 in ?? () #14 0x0806c568 in ?? () #15 0x0806983b in ?? () #16 0x0806a297 in ?? () #17 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x4073d578) at tpool.c:663 #18 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #19 0x405793be in clone () from /lib/libc.so.6 Thread 16 (Thread 11754): #0 0xffffe430 in __kernel_vsyscall () #1 0x40250b3b in write () from /lib/libpthread.so.0 #2 0x4007547b in sb_stream_write (sbiod=0x8425cd0, buf=0x43cbf534, len=120) at sockbuf.c:535 #3 0x400745ba in sb_debug_write (sbiod=0x8425dd8, buf=0x43cbf534, len=120) at sockbuf.c:852 #4 0x400749c2 in ber_int_sb_write (sb=0x45c02a08, buf=0x43cbf534, len=120) at sockbuf.c:445 #5 0x40072244 in ber_flush2 (sb=0x45c02a08, ber=0x43cbba1c, freeit=0) at io.c:256 #6 0x0807a49f in ?? () #7 0x0807cd4e in ?? () #8 0x0807d96f in ?? () #9 0x080fb8ea in ?? () #10 0x080d13d8 in ?? () #11 0x080d2e96 in ?? () #12 0x080d3ad4 in ?? () #13 0x0806bcf3 in ?? () #14 0x080d2f0c in ?? () #15 0x080d3ad4 in ?? () #16 0x0806c568 in ?? () #17 0x0806983b in ?? () #18 0x0806a297 in ?? () #19 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x40739b34) at tpool.c:663 #20 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #21 0x405793be in clone () from /lib/libc.so.6 Thread 15 (Thread 11815): #0 0xffffe430 in __kernel_vsyscall () #1 0x402508dc in __lll_unlock_wake () from /lib/libpthread.so.0 #2 0x4024d0bb in _L_unlock_94 () from /lib/libpthread.so.0 #3 0x4024cccc in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0 #4 0x4003001d in ldap_pvt_thread_mutex_unlock (mutex=0x4073bc24) at thr_posix.c:308 #5 0x0807a63b in ?? () #6 0x0807cd4e in ?? () #7 0x0807d96f in ?? () #8 0x081499f0 in ?? () #9 0x0814ad83 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0808835c in ?? () #13 0x080d2f0c in ?? () #14 0x080d3ad4 in ?? () #15 0x08088e92 in ?? () #16 0x0806983b in ?? () #17 0x0806a297 in ?? () #18 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x4073bcc0) at tpool.c:663 #19 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #20 0x405793be in clone () from /lib/libc.so.6 Thread 14 (Thread 11739): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83d7b58, timeout=0x432b7b20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83d7b58, msgid=943, all=0, timeout=0x432b7c1c, result=0x432b7c34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 13 (Thread 11507): #0 0xffffe430 in __kernel_vsyscall () #1 0x40579c56 in epoll_wait () from /lib/libc.so.6 #2 0x0806627f in ?? () #3 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #4 0x405793be in clone () from /lib/libc.so.6 Thread 12 (Thread 11781): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x838e580, timeout=0x441bdb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x838e580, msgid=588, all=0, timeout=0x441bdc1c, result=0x441bdc34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 11 (Thread 11782): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83ceda8, timeout=0x445beb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83ceda8, msgid=777, all=0, timeout=0x445bec1c, result=0x445bec34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18b3 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 10 (Thread 11749): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83c6820, timeout=0x437babe0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83c6820, msgid=237, all=1, timeout=0x437bac50, result=0x437bac58) at result.c:335 #4 0x08149840 in ?? () #5 0x081520a1 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x08083edb in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08084496 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x437bb0c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 9 (Thread 11813): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83fe760, timeout=0x44bc2be0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83fe760, msgid=457, all=1, timeout=0x44bc2c50, result=0x44bc2c58) at result.c:335 #4 0x08149840 in ?? () #5 0x081520a1 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x08083edb in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08084496 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x44bc30c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 8 (Thread 11697): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x45c050a8, timeout=0x41dafb60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x45c050a8, msgid=446, all=1, timeout=0x41dafbd0, result=0x41dafbd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x41db00c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 7 (Thread 11821): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83adec0, timeout=0x458c69f0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83adec0, msgid=137, all=1, timeout=0x458c6a60, result=0x458c6a68) at result.c:335 #4 0x08149840 in ?? () #5 0x08146d87 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0807100f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08071bab in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x458c70c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 6 (Thread 11717): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83bfbf8, timeout=0x427b3b60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83bfbf8, msgid=17, all=1, timeout=0x427b3bd0, result=0x427b3bd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x427b40c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 5 (Thread 11719): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83fe600, timeout=0x42db69f0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83fe600, msgid=782, all=1, timeout=0x42db6a60, result=0x42db6a68) at result.c:335 #4 0x08149840 in ?? () #5 0x08146d87 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0807100f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08071bab in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x42db70c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 4 (Thread 11703): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83b6ae8, timeout=0x423b2b60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83b6ae8, msgid=18, all=1, timeout=0x423b2bd0, result=0x423b2bd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x423b30c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 3 (Thread 11492): #0 0xffffe430 in __kernel_vsyscall () #1 0x4024a747 in pthread_join () from /lib/libpthread.so.0 #2 0x40030254 in ldap_pvt_thread_join (thread=1085975440, thread_return=0x0) at thr_posix.c:197 #3 0x08063793 in ?? () #4 0x08050f6d in ?? () #5 0x404be705 in __libc_start_main () from /lib/libc.so.6 #6 0x0804f6b1 in ?? () Thread 2 (Thread 11660): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83c0c98, timeout=0x414abb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83c0c98, msgid=445, all=0, timeout=0x414abc1c, result=0x414abc34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 1 (Thread 11679): #0 0xffffe430 in __kernel_vsyscall () #1 0x404d2990 in raise () from /lib/libc.so.6 #2 0x404d42c8 in abort () from /lib/libc.so.6 #3 0x404cb78e in __assert_fail () from /lib/libc.so.6 #4 0x081487f3 in ?? () #5 0x08149515 in ?? () #6 0x081495e3 in ?? () #7 0x0814b039 in ?? () #8 0x080d2f0c in ?? () #9 0x080d3ad4 in ?? () #10 0x0808835c in ?? () #11 0x080d2f0c in ?? () #12 0x080d3ad4 in ?? () #13 0x08088e92 in ?? () #14 0x0806983b in ?? () #15 0x0806a297 in ?? () #16 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #17 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #18 0x405793be in clone () from /lib/libc.so.6

1 0

Re: (ITS#5997) slapo-chain TLS issues
by duramaxlb7＠gmail.com 09 Mar '09

09 Mar '09

--0016364270d292f5780464b1d5a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=XXXX,dc=com" credentials=secret mode=self starttls=yes tls_reqcert=never chain-tls start chain-return-error TRUE ----------- bind as rootdn ---------------------- conn=7 fd=14 ACCEPT from IP=10.1.1.10:42992 (IP=0.0.0.0:389) conn=7 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=7 op=0 STARTTLS conn=7 op=0 RESULT oid= err=0 text= conn=7 fd=14 TLS established tls_ssf=256 ssf=256 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" method=128 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=7 op=1 RESULT tag=97 err=0 text= conn=7 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=7 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=7 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=7 op=3 MOD attr=userPassword userPassword TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. conn=7 op=3 RESULT tag=103 err=52 text= conn=7 op=4 UNBIND conn=7 fd=14 closed ----------- bind as normal user ---------------------- conn=11 fd=14 ACCEPT from IP=10.1.1.10:36765 (IP=0.0.0.0:389) conn=11 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=11 op=0 STARTTLS conn=11 op=0 RESULT oid= err=0 text= conn=11 fd=14 TLS established tls_ssf=256 ssf=256 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=11 op=1 RESULT tag=97 err=0 text= conn=11 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=11 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=11 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=11 op=3 MOD attr=userPassword userPassword conn=11 op=3 RESULT tag=103 err=0 text= conn=11 op=4 UNBIND conn=11 fd=14 closed conn=12 fd=14 ACCEPT from IP=10.1.1.10:36766 (IP=0.0.0.0:389) conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=12 op=0 STARTTLS conn=12 op=0 RESULT oid= err=0 text= conn=12 fd=14 TLS established tls_ssf=256 ssf=256 conn=12 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=12 op=1 RESULT tag=97 err=49 text= conn=13 fd=24 ACCEPT from IP=10.1.1.10:36767 (IP=0.0.0.0:389) conn=13 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=13 op=0 STARTTLS conn=13 op=0 RESULT oid= err=0 text= conn=13 fd=24 TLS established tls_ssf=256 ssf=256 conn=13 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=13 op=1 RESULT tag=97 err=49 text= conn=12 op=2 UNBIND conn=12 fd=14 closed conn=13 op=2 UNBIND conn=13 fd=24 closed --0016364270d292f5780464b1d5a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX c= hain-rebind-as-user TRUE chain-idassert-bind =A0=A0=A0 bindmethod=3Ds= imple =A0=A0=A0 binddn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" = =A0=A0=A0 credentials=3Dsecret =A0=A0=A0 mode=3Dself =A0=A0=A0 starttls=3Dyes =A0=A0=A0 tls_reqcert= =3Dnever chain-tls start chain-return-error TRUE -----= ------ bind as rootdn ---------------------- conn=3D7 fd=3D14 ACCEPT= from IP=3D<a href=3D"http://10.1.1.10:42992">10.1.1.10:42992</a> (IP=3D<a = href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D7 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D7 op=3D0 STARTTL= S conn=3D7 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D7 fd=3D14 TLS = established tls_ssf=3D256 ssf=3D256 conn=3D7 op=3D1 BIND dn=3D"cn= =3DManager,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D7 op=3D1 BIND dn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" mech= =3DSIMPLE ssf=3D0 conn=3D7 op=3D1 RESULT tag=3D97 err=3D0 text=3D con= n=3D7 op=3D2 SRCH base=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dco= m" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)" conn=3D7 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D con= n=3D7 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom&q= uot; conn=3D7 op=3D3 MOD attr=3DuserPassword userPassword TLS certifi= cate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFI= CATE:certificate verify failed. conn=3D7 op=3D3 RESULT tag=3D103 err=3D5= 2 text=3D conn=3D7 op=3D4 UNBIND conn=3D7 fd=3D14 closed -= ---------- bind as normal user ---------------------- conn=3D11 fd=3D14 ACCEPT from IP=3D<a href=3D"http://10.1.1.10:36765">1= 0.1.1.10:36765</a> (IP=3D<a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>)<br= >conn=3D11 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D11 op=3D0 STAR= TTLS conn=3D11 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D11 fd=3D14 TLS established tls_ssf=3D256 ssf=3D256 conn=3D11 op= =3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" me= thod=3D128 conn=3D11 op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,d= c=3DXXXX,dc=3Dcom" mech=3DSIMPLE ssf=3D0 conn=3D11 op=3D1 RESULT tag=3D97 err=3D0 text=3D conn=3D11 op=3D2 SRCH b= ase=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" scope=3D0 d= eref=3D0 filter=3D"(objectClass=3D*)" conn=3D11 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D11 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dc= om" conn=3D11 op=3D3 MOD attr=3DuserPassword userPassword conn= =3D11 op=3D3 RESULT tag=3D103 err=3D0 text=3D conn=3D11 op=3D4 UNBIND<br= >conn=3D11 fd=3D14 closed conn=3D12 fd=3D14 ACCEPT from IP=3D<a href=3D"= http://10.1.1.10:36766">10.1.1.10:36766</a> (IP=3D<a href=3D"http://0.0.0.0= :389">0.0.0.0:389</a>) conn=3D12 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D12 op=3D0 START= TLS conn=3D12 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D12 fd=3D14 = TLS established tls_ssf=3D256 ssf=3D256 conn=3D12 op=3D1 BIND dn=3D&quot= ;uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D12 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D13 fd=3D24 ACCE= PT from IP=3D<a href=3D"http://10.1.1.10:36767">10.1.1.10:36767</a> (IP=3D<= a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D13 op=3D0 EXT oid= =3D1.3.6.1.4.1.1466.20037 conn=3D13 op=3D0 STARTTLS conn=3D13 op=3D0 RESULT oid=3D err=3D0 text=3D= conn=3D13 fd=3D24 TLS established tls_ssf=3D256 ssf=3D256 conn=3D13 = op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" = method=3D128 conn=3D13 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D12 op=3D2 UNBIND conn=3D12 fd=3D14 closed conn=3D13 op=3D2 UNB= IND conn=3D13 fd=3D24 closed --0016364270d292f5780464b1d5a8--

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 Seems to work in HEAD on the very same system. Ciao, Michael.

1 0

(ITS#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.91.160) $ ./run -b bdb test019 Running ./scripts/test019-syncreplication-cascade... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=5018) is running... Waiting 5 seconds for slapd to start... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=5094) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=5126) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=5158) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=5190) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=5222) is running... Using ldapadd to populate the master directory... Waiting 10 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 10 seconds for syncrepl to receive changes... Performing modify alone on provider... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... Using ldapsearch to read all the entries from the P1 slave... Using ldapsearch to read all the entries from the P2 slave... Using ldapsearch to read all the entries from the P3 slave... Filtering master ldapsearch results... Filtering R1 slave ldapsearch results... Filtering R2 slave ldapsearch results... Filtering P1 slave ldapsearch results... Filtering P2 slave ldapsearch results... Filtering P3 slave ldapsearch results... Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... test failed - master and R2 slave databases differ

1 0

Delta-syncrepl and mirrormode
by julien puntous 08 Mar '09

08 Mar '09

HI I am trying to do a mirrormode with 2 servers and deltasyncrepl. Is it possible? We have some problemes with the update referrals, we can t write on the both servers. Thank you, Julien Puntous

2 1

Re: (ITS#5988) entries skipped in n-way mutimaster replication
by hyc＠symas.com 08 Mar '09

08 Mar '09

adrien.futschik(a)atosorigin.com wrote: > Full_Name: Adrien Futschik > Version: 2.4.15 > OS: Linux RHEL 4-5& Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.54.193.59) > > > Hello, > > As suggested by Howard Chu, I am filling an ITS for a problem I encountered when > testing N-way multimaster with OpenLDAP 2.4.15. > > Here is the situation : > > I have been testing n-way multimaster replication with OpenLDAP for a while > now (from 2.4.11, to 2.4.15) and just when I though that everything was > working perfectly, I dicided to test N-way multimaster not only with 2 masters > on different servers, but with 4 ! (all 4 servers are time-synced using NTP) 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.) -- -- 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#6007) README - db.4.7.25.patch no longer used
by hyc＠symas.com 08 Mar '09

08 Mar '09

rich(a)mirch.com wrote: > Full_Name: Rich Mirch > Version: 2.4.15 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.215.53.133) > > > The README REQUIRED SOFTWARE section instructs to install a BDB patch - "In > addition, for BDB 4.7, it is advised to also use the supplied > build/db.4.7.25.patch.". Per the CHANGES document the patch was removed in the > 2.4.14 release. I believe this should be removed from the README file. > Thanks, that note has now been removed. -- -- 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#6008) LDIFReader throws NPE when trying to read an end of stream twice
by a8080＠hushmail.com 07 Mar '09

07 Mar '09

Full_Name: Art Alliany Version: CVS HEAD approx 2.4.14 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.102.51.113) If the end of a LDIF file stream is reached. LDIFReader returns a null which is fine. The problem is that if the LDIFReader is called again after the end of stream is reached it throws a NPE as shown below: java.lang.NullPointerException at com.novell.ldap.util.LDIFReader.readRecordFields(LDIFReader.java:333) at com.novell.ldap.util.LDIFReader.readMessage(LDIFReader.java:273) classes in java.io.* return -1 if you invoke them multiple times so invoking LDIFReader should not throw a null pointer exception if invoked again on a exhausted stream. Here is the fix: I, Art Allisany, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. $ diff -u com/novell/ldap/util/LDIFReader.java.old com/novell/ldap/util/LDIFReader.java.new --- com/novell/ldap/util/LDIFReader.java.old 2009-03-06 02:30:22.000000000 -0800 +++ com/novell/ldap/util/LDIFReader.java.new 2009-03-06 02:34:29.000000000 -0800 @@ -270,6 +270,12 @@ public LDAPMessage readMessage() throws IOException, LDAPException { + if ( this.rFields == null ) { + // end of file has already been reached, this readMessage() + // call has been invoked after the end of the + // ldif file has been reached on previous calls to this method + return null; + } readRecordFields(); // read record fields if ( this.rFields == null ) { // end of file return null;

1 0

Re: (ITS#5982) man page for ldapexop
by ando＠sys-net.it 07 Mar '09

07 Mar '09

> I have put an updated version into > ftp://ftp.openldap.org/incoming/Peter-Marschall-090307-ldapexop.1 Thanks. I'm about to commit it (with minor modifications) unless there's any concern about IPR (Kurt?). 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#5982) man page for ldapexop
by peter＠adpm.de 07 Mar '09

07 Mar '09

Hi, On Monday, 2. March 2009, Gavin Henry wrote: > Could you take a read of: > http://www.openldap.org/devel/contributing.html#notice > [...] Thanks for the hint. I have put an updated version into ftp://ftp.openldap.org/incoming/Peter-Marschall-090307-ldapexop.1 Regards Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#5804) attribute value regex expantion
by hyc＠symas.com 06 Mar '09

06 Mar '09

hyc(a)symas.com wrote: > This has almost inspired me to add substitution to ACL sets... Which I actually added in January 2003, ITS#2285. We really need to document these things... -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs