- openldap-bugs - openldap.org

Re: (ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by hyc＠symas.com 29 Jul '13

29 Jul '13

requate(a)univention.de wrote: > Looks like the patch for ITS#7222 fixed this. > Thanks for the followup. Closing this ITS. -- -- 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#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by requate＠univention.de 29 Jul '13

29 Jul '13

Looks like the patch for ITS#7222 fixed this. -- Arvid Requate Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-52 Fax : +49 421 22232-99 requate(a)univention.de http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

1 0

Re: (ITS#7631) Overlay to rewrite value of attribute using regex
by hyc＠symas.com 29 Jul '13

29 Jul '13

bart(a)icm.edu.pl wrote: > --=_c864110a076fc513331e0370bcb9adbe > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=UTF-8; > format=flowed > > > I put patch here because the ftp server is full. > DB Kurt, the source file in the patch contains this header: @@ -0,0 +1,467 @@ +/* rewatt.c - Overlay to rewrite some attribute */ +/* Redistribution and use in source and binary forms, with or without + * modification, are permitted only as authorized by the OpenLDAP + * Public License. + * + * A copy of this license is available in the file LICENSE in the + * top-level directory of the distribution or, alternatively, at + * <http://www.OpenLDAP.org/license.html>. + */ +/* ACKNOWLEDGEMENTS: + * This work was originally developed by the Dominik Bartkiewicz bart(a)icm.edu.pl for + * inclusion in OpenLDAP Software. + */ I presume we still need a formal IPR notice in the ITS? -- -- 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#7642) make test for AIX fails on test060-mt-hot
by fumiyas＠osstech.jp 28 Jul '13

28 Jul '13

At Sat, 27 Jul 2013 16:59:07 GMT, mamfelt(a)gmail.com wrote: > 1) also did .35 version, same message > 2) these, except for filesize, are the defaults for at least the last 10 > years: > time(seconds) unlimited > file(blocks) unlimited > data(kbytes) 131072 > stack(kbytes) 32768 > memory(kbytes) 32768 > coredump(blocks) 2097151 > nofiles(descriptors) 2000 Please do `export LDR_CNTRL=MAXDATA=0x20000000` and retry test060. > Now, it is perhaps possible that the data/memory/ and/or stack size is too > small. I shall check on the test system to see if the defaults are the same > as above, or if all have been reset. > I'll even look for a coredump to see if it says anything more about what > has happened. -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 28 Jul '13

28 Jul '13

--001a11c37b0a23a7cd04e2943a0d Content-Type: text/plain; charset=ISO-8859-1 I tried recompiling the Berkeley db (6.0.20) with -D_LARGE_THREADS, no difference. I modified the test to use THR=50 and INNER ...*4 so it looks like this: ===== # Perform a basic multi-threaded search on a single connection THR=100 THR=50 OUTER=5 INNER=`expr $TESTLOOPS \* 4` echo "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) loops..." echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ -e "$MONITORDN" \ -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ -e "$MONITORDN" -f "(objectclass=*)" \ -m $THR -L $OUTER -l $INNER >> $MTREADOUT 2>&1 RC=$? if test $RC != 0 ; then echo "slapd-mtread failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi ======= and the tests complete. Not sure how arbitrary the THR=100 is, but the 50k transactions is maintained (50 * 5 * 50 * 4) versus (100 * 5 * 50 * 2) ==== In short, using THR=50, and doubled INNER factor test060 succeeds. Now - dies this break the test, or just show a different issue? Michael On Sun, Jul 28, 2013 at 3:57 PM, Michael Felt <mamfelt(a)gmail.com> wrote: > After the new configure with -D_LARGE_THREADS still same status: > root@x094:[/data/prj/openldap-2.4.35/tests]./run test060 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test060-mt-hot for bdb... > > running defines.sh > Running slapadd to build slapd database... > Running slapindex to index slapd database... > Starting slapd on TCP/IP port 9011... > /data/prj/openldap-2.4.35/tests/../servers/slapd/slapd -s0 -f > /data/prj/openldap-2.4.35/tests/testrun/slapd.1.conf -h > ldap://localhost:9011/ -d stats > Testing basic monitor search... > Monitor searches > Testing basic mt-hot search: 1 threads (1 x 50000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 > Testing basic mt-hot search: 5 threads (1 x 10000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 > Testing basic mt-hot search: 100 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 > slapd-mtread failed (1)! > root@x094:[/data/prj/openldap-2.4.35/tests]echo $? > 1 > > > On Sun, Jul 28, 2013 at 2:23 PM, Michael Felt <mamfelt(a)gmail.com> wrote: > >> Note: tried nofiles=5000 and nofiles=10000 - no change. >> >> I am beginning to think it could be related to this: >> >> *Limits and Default Values* >> The threads library has some implementation-dependent limits and default >> values. These limits and default values can be retrieved by symbolic >> constants to enhance the portability of programs: >> >> - The maximum number of threads per process is 512. The maximum >> number of threads can be retrieved at compilation time using the * >> PTHREAD_THREADS_MAX* symbolic constant defined in the *pthread.h*header file. If an application is compiled with the >> *-D_LARGE_THREADS* flag, the maximum number of threads per process is >> 32767. >> >> === >> >> Made this small change to the test: >> >> # Perform a basic multi-threaded search on a single connection >> echo Perform a basic multi-threaded search on a single connection >> THR=100 >> OUTER=5 >> INNER=`expr $TESTLOOPS \* 2` >> for THR in 60 62 64 65 66 67 68 69 70 80 90 100 >> do >> echo "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) >> loops..." >> echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ >> -e "$MONITORDN" \ >> -m $THR -L $OUTER -l $INNER >> $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ >> -e "$MONITORDN" -f "(objectclass=*)" \ >> -m $THR -L $OUTER -l $INNER >> $MTREADOUT 2>&1 >> RC=$? >> if test $RC != 0 ; then >> echo "slapd-mtread failed ($RC)!" >> test $KILLSERVERS != no && kill -HUP $KILLPIDS >> exit $RC >> fi >> done >> >> Got this as output: >> >> Testing basic monitor search... >> Monitor searches >> Testing basic mt-hot search: 1 threads (1 x 50000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 >> Testing basic mt-hot search: 5 threads (1 x 10000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 >> Perform a basic multi-threaded search on a single connection >> Testing basic mt-hot search: 60 threads (5 x 100) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 60 -L 5 -l 100 >> Testing basic mt-hot search: 62 threads (5 x 100) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 62 -L 5 -l 100 >> Testing basic mt-hot search: 64 threads (5 x 100) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 64 -L 5 -l 100 >> slapd-mtread failed (1)! >> root@x054:[/data/prj/openldap-2.4.35/tests] >> >> ==== >> >> slapd-mtread PID=6750246: MT Test Start: conns: 1 (ldap://localhost:9011/) >> slapd-mtread PID=6750246: Threads: RO: 64 RW: 0 >> slapd-mtread PID=6750246: RO thread 0 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 1 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 2 pass=500 fail=0 >> >> ... >> >> slapd-mtread PID=6750246: RO thread 59 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 60 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 61 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 62 pass=500 fail=0 >> slapd-mtread PID=6750246: RO thread 63 pass=0 fail=0 >> slapd-mtread PID=6750246: FAIL RO thread 63 >> slapd-mtread PID=6750246: MT Test complete >> >> === >> >> Back to original test, mtread.out tail is: >> >> slapd-mtread PID=5242956: RO thread 60 pass=500 fail=0 >> slapd-mtread PID=5242956: RO thread 61 pass=500 fail=0 >> slapd-mtread PID=5242956: RO thread 62 pass=500 fail=0 >> slapd-mtread PID=5242956: RO thread 63 pass=0 fail=0 >> slapd-mtread PID=5242956: FAIL RO thread 63 >> slapd-mtread PID=5242956: RO thread 64 pass=0 fail=0 >> slapd-mtread PID=5242956: FAIL RO thread 64 >> slapd-mtread PID=5242956: RO thread 65 pass=0 fail=0 >> .... >> >> slapd-mtread PID=5242956: FAIL RO thread 97 >> slapd-mtread PID=5242956: RO thread 98 pass=0 fail=0 >> slapd-mtread PID=5242956: FAIL RO thread 98 >> slapd-mtread PID=5242956: RO thread 99 pass=0 fail=0 >> slapd-mtread PID=5242956: FAIL RO thread 99 >> slapd-mtread PID=5242956: MT Test complete >> >> === >> >> Shall test after new build with CFLAGS=-D_LARGE_THREADS >> >> >> On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <hyc(a)symas.com> wrote: >> >>> Michael Felt wrote: >>> >>>> The log file did not show any errors. >>>> >>> >>> If there's no server side errors then I suppose it's a problem in >>> mtread. Check the testrun/mtread.out file. >>> >>> >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> >>> >> >> > --001a11c37b0a23a7cd04e2943a0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I tried recompiling the Berkeley db (6.0.20) with -D_LARGE_THREADS, no diff= erence. I modified the test to use THR=3D50 and INNER ...*4 so it lo= oks like this: =3D=3D=3D=3D=3D # Perform a basic multi-threaded searc= h on a single connection THR=3D100 THR=3D50 OUTER=3D5 INNER=3D`expr $TESTLOOPS \* 4` ech= o "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) loops..= ." echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD = \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" \ =A0=A0=A0=A0=A0=A0=A0 = -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN&qu= ot; -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" -f &quo= t;(objectclass=3D*)" \ =A0=A0=A0=A0=A0=A0=A0 -m $THR -L $OUTER -l $= INNER >> $MTREADOUT 2>&1 RC=3D$? if test $RC !=3D 0 ; then =A0=A0=A0=A0=A0=A0=A0 echo "sl= apd-mtread failed ($RC)!" =A0=A0=A0=A0=A0=A0=A0 test $KILLSERVERS != =3D no && kill -HUP $KILLPIDS =A0=A0=A0=A0=A0=A0=A0 exit $RC = fi =3D=3D=3D=3D=3D=3D=3D and the tests complete. Not sure how arbitra= ry the THR=3D100 is, but the 50k transactions is maintained (50 * 5 * 50 * 4) versus (100 * 5 * 50 * 2) =3D=3D=3D=3D In short, us= ing THR=3D50, and doubled INNER factor test060 succeeds. Now - dies = this break the test, or just show a different issue? Michael <div= class=3D"gmail_quote"> On Sun, Jul 28, 2013 at 3:57 PM, Michael Felt <<a href= =3D"mailto:mamfelt@gmail.com" target=3D"_blank">mamfelt(a)gmail.com</a>></= span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> After the new configure with -D_LARGE_THREADS still same status: root@x094:[/data/prj/openldap-2.= 4.35/tests]./run test060 Cleaning up test run directory leftover from pr= evious run. Running ./scripts/test060-mt-hot for bdb...<div class=3D"im"> running de= fines.sh Running slapadd to build slapd database... Running slapindex= to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.35/tests/../servers/slapd/slapd -s0 -f /data/prj/ope= nldap-2.4.35/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats<= br></div><div class=3D"im"> Testing basic monitor search... Monitor searches Testing basic mt-hot= search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://l= ocalhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DMoni= tor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 </div>Testing basic mt-hot se= arch: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread fail= ed (1)! root@x094:[/data/prj/openldap-2.4.35/tests]echo $? 1 </spa= n><div class=3D"HOEnZb"> <div class=3D"h5"> <div class=3D"gmail_quote">On Sun, Jul 28, 2013 at 2:23 PM, Michael Fel= t <<a href=3D"mailto:mamfelt@gmail.com" target=3D"_bla= nk">mamfelt(a)gmail.com</a>> wrote: <blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> Note: tried nofiles=3D5000 and nofiles=3D10000 - no change. I am beg= inning to think it could be related to this: Limits and Default Va= lues The threads library has some implementation-dependent limits and default values. These limits and default values can be retrieved by symbolic constants to enhance the portability of programs: <ul><li>The maxi= mum number of threads per process is 512. The maximum number of threads can be retrieved at compilation time using the PTHREAD= _THREADS_MAX symbolic constant defined in the pthread.h header file. If an application is compiled with the -D_LARGE_THREADS flag, the maximum number of threads per process is 32767.</li></ul>=3D=3D=3DMade this smal= l change to the test:# Perform = a basic multi-threaded search on a single connection echo Perform a basi= c multi-threaded search on a single connection THR=3D100 OUTER=3D5 INNER=3D`expr $TESTLOOPS \* 2` for THR in 60 6= 2 64 65 66 67 68 69 70 80 90 100 do echo "Testing basic mt-hot s= earch: $THR threads ($OUTER x $INNER) loops..." echo $SLAPDMTREAD -= H $URI1 -D "$MANAGERDN" -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" \ =A0=A0=A0=A0=A0=A0=A0 = -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN&qu= ot; -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" -f &quo= t;(objectclass=3D*)" \ =A0=A0=A0=A0=A0=A0=A0 -m $THR -L $OUTER -l $= INNER >> $MTREADOUT 2>&1 RC=3D$? if test $RC !=3D 0 ; then =A0=A0=A0=A0=A0=A0=A0 echo "sl= apd-mtread failed ($RC)!" =A0=A0=A0=A0=A0=A0=A0 test $KILLSERVERS != =3D no && kill -HUP $KILLPIDS =A0=A0=A0=A0=A0=A0=A0 exit $RC = fi done Got this as output: <div>Testing basic monitor search... Monitor searches Testing = basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread= -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret = -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 </div>Perform a basic multi-t= hreaded search on a single connection Testing basic mt-hot search: 60 threads (5 x 100) loops... ./progs/slapd= -mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w = secret -e cn=3DMonitor -m 60 -L 5 -l 100 Testing basic mt-hot search: 62= threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 62 -L 5 -l 100 Testing basic mt-h= ot search: 64 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://= localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DMon= itor -m 64 -L 5 -l 100 slapd-mtread failed (1)! root@x054:[/data/prj/openldap-2.4.35/tests] = =3D=3D=3D=3Dslapd-mtread PID=3D6750246: MT Test Start: con= ns: 1 (ldap://localhost:9011/) slapd-mtread PID=3D6750246: Threads: RO: = 64 RW: 0 slapd-mtread PID=3D6750246: RO thread 0 pass=3D500 fail=3D0 slapd-mtread= PID=3D6750246: RO thread 1 pass=3D500 fail=3D0 slapd-mtread PID=3D67502= 46: RO thread 2 pass=3D500 fail=3D0 ...slapd-mtread PID=3D= 6750246: RO thread 59 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO thread 60 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D6750246: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D675= 0246: RO thread 62 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO th= read 63 pass=3D0 fail=3D0 slapd-mtread PID=3D6750246: FAIL RO thread 63 slapd-mtread PID=3D6750246= : MT Test complete =3D=3D=3DBack to original test, mtread.= out tail is:slapd-mtread PID=3D5242956: RO thread 60 pass=3D500 fail= =3D0 slapd-mtread PID=3D5242956: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D5242956: RO thread 62 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D5242956: RO thread 63 pass=3D0 fail=3D0 slapd-mtread PID=3D52429= 56: FAIL RO thread 63 slapd-mtread PID=3D5242956: RO thread 64 pass=3D0 = fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 64 slapd-mtread PID=3D5242956: RO thread 65 pass=3D0 fail=3D0 ....sl= apd-mtread PID=3D5242956: FAIL RO thread 97 slapd-mtread PID=3D5242956: = RO thread 98 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO threa= d 98 slapd-mtread PID=3D5242956: RO thread 99 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 99 slapd-mtread PID=3D5242956= : MT Test complete =3D=3D=3DShall test after new build wit= h CFLAGS=3D-D_LARGE_THREADS <div><div> <div class=3D"gmail_qu= ote"> On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <<a href= =3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> wr= ote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div>Michael Felt wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The log file did not show any errors. </blockquote> </div> If there's no server side errors then I suppose it's a problem in m= tread. Check the testrun/mtread.out file. -- <div><div> =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> </div></div></blockquote></div> </div></div></blockquote></div> --001a11c37b0a23a7cd04e2943a0d--

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by hyc＠symas.com 28 Jul '13

28 Jul '13

Michael Felt wrote: > Note: tried nofiles=5000 and nofiles=10000 - no change. > > I am beginning to think it could be related to this: > > *Limits and Default Values* Nah. If the limit on threads is 512 and this test is only spawning 100 threads, that's clearly not the issue. More likely it's the datasize or memorysize limit, since we allocate 8MB per thread for its stack. Change your memory limit to unlimited. In any case, I wouldn't worry about it if you can't get this test to run; clearly the server has no issues if it got that far. > > The threads library has some implementation-dependent limits and default > values. These limits and default values can be retrieved by symbolic constants > to enhance the portability of programs: > > * The maximum number of threads per process is 512. The maximum number of > threads can be retrieved at compilation time using the > *PTHREAD_THREADS_MAX* symbolic constant defined in the *pthread.h* header > file. If an application is compiled with the *-D_LARGE_THREADS* flag, the > maximum number of threads per process is 32767. > > === > > Made this small change to the test: > > # Perform a basic multi-threaded search on a single connection > echo Perform a basic multi-threaded search on a single connection > THR=100 > OUTER=5 > INNER=`expr $TESTLOOPS \* 2` > for THR in 60 62 64 65 66 67 68 69 70 80 90 100 > do > echo "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) loops..." > echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ > -e "$MONITORDN" \ > -m $THR -L $OUTER -l $INNER > $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ > -e "$MONITORDN" -f "(objectclass=*)" \ > -m $THR -L $OUTER -l $INNER >> $MTREADOUT 2>&1 > RC=$? > if test $RC != 0 ; then > echo "slapd-mtread failed ($RC)!" > test $KILLSERVERS != no && kill -HUP $KILLPIDS > exit $RC > fi > done > > Got this as output: > > Testing basic monitor search... > Monitor searches > Testing basic mt-hot search: 1 threads (1 x 50000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 1 -L 1 -l 50000 > Testing basic mt-hot search: 5 threads (1 x 10000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 5 -L 1 -l 10000 > Perform a basic multi-threaded search on a single connection > Testing basic mt-hot search: 60 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 60 -L 5 -l 100 > Testing basic mt-hot search: 62 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 62 -L 5 -l 100 > Testing basic mt-hot search: 64 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 64 -L 5 -l 100 > slapd-mtread failed (1)! > root@x054:[/data/prj/openldap-2.4.35/tests] > > ==== > > slapd-mtread PID=6750246: MT Test Start: conns: 1 (ldap://localhost:9011/) > slapd-mtread PID=6750246: Threads: RO: 64 RW: 0 > slapd-mtread PID=6750246: RO thread 0 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 1 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 2 pass=500 fail=0 > > ... > > slapd-mtread PID=6750246: RO thread 59 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 60 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 61 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 62 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 63 pass=0 fail=0 > slapd-mtread PID=6750246: FAIL RO thread 63 > slapd-mtread PID=6750246: MT Test complete > > === > > Back to original test, mtread.out tail is: > > slapd-mtread PID=5242956: RO thread 60 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 61 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 62 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 63 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 63 > slapd-mtread PID=5242956: RO thread 64 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 64 > slapd-mtread PID=5242956: RO thread 65 pass=0 fail=0 > .... > > slapd-mtread PID=5242956: FAIL RO thread 97 > slapd-mtread PID=5242956: RO thread 98 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 98 > slapd-mtread PID=5242956: RO thread 99 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 99 > slapd-mtread PID=5242956: MT Test complete > > === > > Shall test after new build with CFLAGS=-D_LARGE_THREADS > > > > On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Michael Felt wrote: > > The log file did not show any errors. > > > If there's no server side errors then I suppose it's a problem in mtread. > Check the testrun/mtread.out file. > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 28 Jul '13

28 Jul '13

--089e0112c86ef0022b04e292c264 Content-Type: text/plain; charset=ISO-8859-1 After the new configure with -D_LARGE_THREADS still same status: root@x094:[/data/prj/openldap-2.4.35/tests]./run test060 Cleaning up test run directory leftover from previous run. Running ./scripts/test060-mt-hot for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.35/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.35/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! root@x094:[/data/prj/openldap-2.4.35/tests]echo $? 1 On Sun, Jul 28, 2013 at 2:23 PM, Michael Felt <mamfelt(a)gmail.com> wrote: > Note: tried nofiles=5000 and nofiles=10000 - no change. > > I am beginning to think it could be related to this: > > *Limits and Default Values* > The threads library has some implementation-dependent limits and default > values. These limits and default values can be retrieved by symbolic > constants to enhance the portability of programs: > > - The maximum number of threads per process is 512. The maximum number > of threads can be retrieved at compilation time using the * > PTHREAD_THREADS_MAX* symbolic constant defined in the *pthread.h*header file. If an application is compiled with the > *-D_LARGE_THREADS* flag, the maximum number of threads per process is > 32767. > > === > > Made this small change to the test: > > # Perform a basic multi-threaded search on a single connection > echo Perform a basic multi-threaded search on a single connection > THR=100 > OUTER=5 > INNER=`expr $TESTLOOPS \* 2` > for THR in 60 62 64 65 66 67 68 69 70 80 90 100 > do > echo "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) loops..." > echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ > -e "$MONITORDN" \ > -m $THR -L $OUTER -l $INNER > $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ > -e "$MONITORDN" -f "(objectclass=*)" \ > -m $THR -L $OUTER -l $INNER >> $MTREADOUT 2>&1 > RC=$? > if test $RC != 0 ; then > echo "slapd-mtread failed ($RC)!" > test $KILLSERVERS != no && kill -HUP $KILLPIDS > exit $RC > fi > done > > Got this as output: > > Testing basic monitor search... > Monitor searches > Testing basic mt-hot search: 1 threads (1 x 50000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 > Testing basic mt-hot search: 5 threads (1 x 10000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 > Perform a basic multi-threaded search on a single connection > Testing basic mt-hot search: 60 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 60 -L 5 -l 100 > Testing basic mt-hot search: 62 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 62 -L 5 -l 100 > Testing basic mt-hot search: 64 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D > cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 64 -L 5 -l 100 > slapd-mtread failed (1)! > root@x054:[/data/prj/openldap-2.4.35/tests] > > ==== > > slapd-mtread PID=6750246: MT Test Start: conns: 1 (ldap://localhost:9011/) > slapd-mtread PID=6750246: Threads: RO: 64 RW: 0 > slapd-mtread PID=6750246: RO thread 0 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 1 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 2 pass=500 fail=0 > > ... > > slapd-mtread PID=6750246: RO thread 59 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 60 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 61 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 62 pass=500 fail=0 > slapd-mtread PID=6750246: RO thread 63 pass=0 fail=0 > slapd-mtread PID=6750246: FAIL RO thread 63 > slapd-mtread PID=6750246: MT Test complete > > === > > Back to original test, mtread.out tail is: > > slapd-mtread PID=5242956: RO thread 60 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 61 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 62 pass=500 fail=0 > slapd-mtread PID=5242956: RO thread 63 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 63 > slapd-mtread PID=5242956: RO thread 64 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 64 > slapd-mtread PID=5242956: RO thread 65 pass=0 fail=0 > .... > > slapd-mtread PID=5242956: FAIL RO thread 97 > slapd-mtread PID=5242956: RO thread 98 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 98 > slapd-mtread PID=5242956: RO thread 99 pass=0 fail=0 > slapd-mtread PID=5242956: FAIL RO thread 99 > slapd-mtread PID=5242956: MT Test complete > > === > > Shall test after new build with CFLAGS=-D_LARGE_THREADS > > > On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <hyc(a)symas.com> wrote: > >> Michael Felt wrote: >> >>> The log file did not show any errors. >>> >> >> If there's no server side errors then I suppose it's a problem in mtread. >> Check the testrun/mtread.out file. >> >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> >> > > --089e0112c86ef0022b04e292c264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After the new configure with -D_LARGE_THREADS still same status: root@x094:[/data/prj/openldap-2.= 4.35/tests]./run test060 Cleaning up test run directory leftover from pr= evious run. Running ./scripts/test060-mt-hot for bdb... running defines.sh Runnin= g slapadd to build slapd database... Running slapindex to index slapd da= tabase... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.= 4.35/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.35/tests/te= strun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot= search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://l= ocalhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DMoni= tor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: = 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread fail= ed (1)! root@x094:[/data/prj/openldap-2.4.35/tests]echo $? 1 </spa= n> <div class=3D"gmail_quote">On Sun, Jul 28, 2013 at 2:23 PM, Michael Fel= t <<a href=3D"mailto:mamfelt@gmail.com" target=3D"_bla= nk">mamfelt(a)gmail.com</a>> wrote: <blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> Note: tried nofiles=3D5000 and nofiles=3D10000 - no change. I am beg= inning to think it could be related to this: Limits and Default Va= lues The threads library has some implementation-dependent limits and default values. These limits and default values can be retrieved by symbolic constants to enhance the portability of programs: <ul><li>The maxi= mum number of threads per process is 512. The maximum number of threads can be retrieved at compilation time using the PTHREAD= _THREADS_MAX symbolic constant defined in the pthread.h header file. If an application is compiled with the -D_LARGE_THREADS flag, the maximum number of threads per process is 32767.</li></ul>=3D=3D=3DMade this smal= l change to the test:# Perform = a basic multi-threaded search on a single connection echo Perform a basi= c multi-threaded search on a single connection THR=3D100 OUTER=3D5 INNER=3D`expr $TESTLOOPS \* 2` for THR in 60 6= 2 64 65 66 67 68 69 70 80 90 100 do echo "Testing basic mt-hot s= earch: $THR threads ($OUTER x $INNER) loops..." echo $SLAPDMTREAD -= H $URI1 -D "$MANAGERDN" -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" \ =A0=A0=A0=A0=A0=A0=A0 = -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN&qu= ot; -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" -f &quo= t;(objectclass=3D*)" \ =A0=A0=A0=A0=A0=A0=A0 -m $THR -L $OUTER -l $= INNER >> $MTREADOUT 2>&1 RC=3D$? if test $RC !=3D 0 ; then =A0=A0=A0=A0=A0=A0=A0 echo "sl= apd-mtread failed ($RC)!" =A0=A0=A0=A0=A0=A0=A0 test $KILLSERVERS != =3D no && kill -HUP $KILLPIDS =A0=A0=A0=A0=A0=A0=A0 exit $RC = fi done Got this as output: <div class=3D"im">Testing basic monitor search... Monitor searche= s Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs= /slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dc= om -w secret -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 </div>Perform a basic multi-t= hreaded search on a single connection Testing basic mt-hot search: 60 threads (5 x 100) loops... ./progs/slapd= -mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w = secret -e cn=3DMonitor -m 60 -L 5 -l 100 Testing basic mt-hot search: 62= threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 62 -L 5 -l 100 Testing basic mt-h= ot search: 64 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://= localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DMon= itor -m 64 -L 5 -l 100 slapd-mtread failed (1)! root@x054:[/data/prj/openldap-2.4.35/tests] = =3D=3D=3D=3Dslapd-mtread PID=3D6750246: MT Test Start: con= ns: 1 (ldap://localhost:9011/) slapd-mtread PID=3D6750246: Threads: RO: = 64 RW: 0 slapd-mtread PID=3D6750246: RO thread 0 pass=3D500 fail=3D0 slapd-mtread= PID=3D6750246: RO thread 1 pass=3D500 fail=3D0 slapd-mtread PID=3D67502= 46: RO thread 2 pass=3D500 fail=3D0 ...slapd-mtread PID=3D= 6750246: RO thread 59 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO thread 60 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D6750246: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D675= 0246: RO thread 62 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO th= read 63 pass=3D0 fail=3D0 slapd-mtread PID=3D6750246: FAIL RO thread 63 slapd-mtread PID=3D6750246= : MT Test complete =3D=3D=3DBack to original test, mtread.= out tail is:slapd-mtread PID=3D5242956: RO thread 60 pass=3D500 fail= =3D0 slapd-mtread PID=3D5242956: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D5242956: RO thread 62 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D5242956: RO thread 63 pass=3D0 fail=3D0 slapd-mtread PID=3D52429= 56: FAIL RO thread 63 slapd-mtread PID=3D5242956: RO thread 64 pass=3D0 = fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 64 slapd-mtread PID=3D5242956: RO thread 65 pass=3D0 fail=3D0 ....sl= apd-mtread PID=3D5242956: FAIL RO thread 97 slapd-mtread PID=3D5242956: = RO thread 98 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO threa= d 98 slapd-mtread PID=3D5242956: RO thread 99 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 99 slapd-mtread PID=3D5242956= : MT Test complete =3D=3D=3DShall test after new build wit= h CFLAGS=3D-D_LARGE_THREADS <div class=3D"HOEnZb"><div class=3D"h5">= <div class=3D"gmail_quote"> On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <<a href= =3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> wr= ote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div>Michael Felt wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The log file did not show any errors. </blockquote> </div> If there's no server side errors then I suppose it's a problem in m= tread. Check the testrun/mtread.out file. -- <div><div> =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> </div></div></blockquote></div> --089e0112c86ef0022b04e292c264--

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 28 Jul '13

28 Jul '13

--001a11334f8a1e9c1f04e29172ba Content-Type: text/plain; charset=ISO-8859-1 Note: tried nofiles=5000 and nofiles=10000 - no change. I am beginning to think it could be related to this: *Limits and Default Values* The threads library has some implementation-dependent limits and default values. These limits and default values can be retrieved by symbolic constants to enhance the portability of programs: - The maximum number of threads per process is 512. The maximum number of threads can be retrieved at compilation time using the * PTHREAD_THREADS_MAX* symbolic constant defined in the *pthread.h* header file. If an application is compiled with the *-D_LARGE_THREADS* flag, the maximum number of threads per process is 32767. === Made this small change to the test: # Perform a basic multi-threaded search on a single connection echo Perform a basic multi-threaded search on a single connection THR=100 OUTER=5 INNER=`expr $TESTLOOPS \* 2` for THR in 60 62 64 65 66 67 68 69 70 80 90 100 do echo "Testing basic mt-hot search: $THR threads ($OUTER x $INNER) loops..." echo $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ -e "$MONITORDN" \ -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN" -w $PASSWD \ -e "$MONITORDN" -f "(objectclass=*)" \ -m $THR -L $OUTER -l $INNER >> $MTREADOUT 2>&1 RC=$? if test $RC != 0 ; then echo "slapd-mtread failed ($RC)!" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit $RC fi done Got this as output: Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Perform a basic multi-threaded search on a single connection Testing basic mt-hot search: 60 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 60 -L 5 -l 100 Testing basic mt-hot search: 62 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 62 -L 5 -l 100 Testing basic mt-hot search: 64 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 64 -L 5 -l 100 slapd-mtread failed (1)! root@x054:[/data/prj/openldap-2.4.35/tests] ==== slapd-mtread PID=6750246: MT Test Start: conns: 1 (ldap://localhost:9011/) slapd-mtread PID=6750246: Threads: RO: 64 RW: 0 slapd-mtread PID=6750246: RO thread 0 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 1 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 2 pass=500 fail=0 ... slapd-mtread PID=6750246: RO thread 59 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 60 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 61 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 62 pass=500 fail=0 slapd-mtread PID=6750246: RO thread 63 pass=0 fail=0 slapd-mtread PID=6750246: FAIL RO thread 63 slapd-mtread PID=6750246: MT Test complete === Back to original test, mtread.out tail is: slapd-mtread PID=5242956: RO thread 60 pass=500 fail=0 slapd-mtread PID=5242956: RO thread 61 pass=500 fail=0 slapd-mtread PID=5242956: RO thread 62 pass=500 fail=0 slapd-mtread PID=5242956: RO thread 63 pass=0 fail=0 slapd-mtread PID=5242956: FAIL RO thread 63 slapd-mtread PID=5242956: RO thread 64 pass=0 fail=0 slapd-mtread PID=5242956: FAIL RO thread 64 slapd-mtread PID=5242956: RO thread 65 pass=0 fail=0 .... slapd-mtread PID=5242956: FAIL RO thread 97 slapd-mtread PID=5242956: RO thread 98 pass=0 fail=0 slapd-mtread PID=5242956: FAIL RO thread 98 slapd-mtread PID=5242956: RO thread 99 pass=0 fail=0 slapd-mtread PID=5242956: FAIL RO thread 99 slapd-mtread PID=5242956: MT Test complete === Shall test after new build with CFLAGS=-D_LARGE_THREADS On Sun, Jul 28, 2013 at 1:19 PM, Howard Chu <hyc(a)symas.com> wrote: > Michael Felt wrote: > >> The log file did not show any errors. >> > > If there's no server side errors then I suppose it's a problem in mtread. > Check the testrun/mtread.out file. > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --001a11334f8a1e9c1f04e29172ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note: tried nofiles=3D5000 and nofiles=3D10000 - no change. I am beg= inning to think it could be related to this: Limits and Default Values The threads library has some implementation-dependent limits and default values. These limits and default values can be retrieved by symbolic constants to enhance the portability of programs: <ul class=3D"ul"= ><li class=3D"li">The maximum number of threads per process is 512. The max= imum number of threads can be retrieved at compilation time using the PTHREAD_THREADS_MAX symbolic constant defined in the pthread.h header fi= le. If an application is compiled with the -D_LARGE_THREADS flag,= the maximum number of threads per process is 32767.</li></ul>=3D=3D=3DMade this smal= l change to the test:# Perform = a basic multi-threaded search on a single connection echo Perform a basi= c multi-threaded search on a single connection THR=3D100 OUTER=3D5 INNER=3D`expr $TESTLOOPS \* 2` for THR in 60 6= 2 64 65 66 67 68 69 70 80 90 100 do echo "Testing basic mt-hot s= earch: $THR threads ($OUTER x $INNER) loops..." echo $SLAPDMTREAD -= H $URI1 -D "$MANAGERDN" -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" \ =A0=A0=A0=A0=A0=A0=A0 = -m $THR -L $OUTER -l $INNER $SLAPDMTREAD -H $URI1 -D "$MANAGERDN&qu= ot; -w $PASSWD \ =A0=A0=A0=A0=A0=A0=A0 -e "$MONITORDN" -f &quo= t;(objectclass=3D*)" \ =A0=A0=A0=A0=A0=A0=A0 -m $THR -L $OUTER -l $= INNER >> $MTREADOUT 2>&1 RC=3D$? if test $RC !=3D 0 ; then =A0=A0=A0=A0=A0=A0=A0 echo "sl= apd-mtread failed ($RC)!" =A0=A0=A0=A0=A0=A0=A0 test $KILLSERVERS != =3D no && kill -HUP $KILLPIDS =A0=A0=A0=A0=A0=A0=A0 exit $RC = fi done Got this as output: Testing basic monitor search... Monitor searches Testing basic mt-= hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap:= //localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DM= onitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Perform a basic multi-threade= d search on a single connection Testing basic mt-hot search: 60 threads (5 x 100) loops... ./progs/slapd= -mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w = secret -e cn=3DMonitor -m 60 -L 5 -l 100 Testing basic mt-hot search: 62= threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 62 -L 5 -l 100 Testing basic mt-h= ot search: 64 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://= localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w secret -e cn=3DMon= itor -m 64 -L 5 -l 100 slapd-mtread failed (1)! root@x054:[/data/prj/openldap-2.4.35/tests] = =3D=3D=3D=3Dslapd-mtread PID=3D6750246: MT Test Start: conns:= 1 (ldap://localhost:9011/) slapd-mtread PID=3D6750246: Threads: RO: 64 = RW: 0 slapd-mtread PID=3D6750246: RO thread 0 pass=3D500 fail=3D0 slapd-mtread= PID=3D6750246: RO thread 1 pass=3D500 fail=3D0 slapd-mtread PID=3D67502= 46: RO thread 2 pass=3D500 fail=3D0 ...slapd-mtread PID=3D= 6750246: RO thread 59 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO thread 60 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D6750246: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D675= 0246: RO thread 62 pass=3D500 fail=3D0 slapd-mtread PID=3D6750246: RO th= read 63 pass=3D0 fail=3D0 slapd-mtread PID=3D6750246: FAIL RO thread 63 slapd-mtread PID=3D6750246= : MT Test complete =3D=3D=3DBack to original test, mtread.= out tail is:slapd-mtread PID=3D5242956: RO thread 60 pass=3D500 fail= =3D0 slapd-mtread PID=3D5242956: RO thread 61 pass=3D500 fail=3D0 slapd-mtread PID=3D5242956: RO thread 62 pass=3D500 fail=3D0 slapd-mtrea= d PID=3D5242956: RO thread 63 pass=3D0 fail=3D0 slapd-mtread PID=3D52429= 56: FAIL RO thread 63 slapd-mtread PID=3D5242956: RO thread 64 pass=3D0 = fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 64 slapd-mtread PID=3D5242956: RO thread 65 pass=3D0 fail=3D0 ....sl= apd-mtread PID=3D5242956: FAIL RO thread 97 slapd-mtread PID=3D5242956: = RO thread 98 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO threa= d 98 slapd-mtread PID=3D5242956: RO thread 99 pass=3D0 fail=3D0 slapd-mtread PID=3D5242956: FAIL RO thread 99 slapd-mtread PID=3D5242956= : MT Test complete =3D=3D=3DShall test after new build wit= h CFLAGS=3D-D_LARGE_THREADS <div class=3D"gmail_quote">On Su= n, Jul 28, 2013 at 1:19 PM, Howard Chu <<a href=3D"mai= lto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> wrote:<br= > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">Michael Felt wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The log file did not show any errors. </blockquote> </div> If there's no server side errors then I suppose it's a problem in m= tread. Check the testrun/mtread.out file. -- <div class=3D"HOEnZb"><div class=3D"h5"> =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> --001a11334f8a1e9c1f04e29172ba--

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by hyc＠symas.com 28 Jul '13

28 Jul '13

Michael Felt wrote: > The log file did not show any errors. If there's no server side errors then I suppose it's a problem in mtread. Check the testrun/mtread.out file. -- -- 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#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 28 Jul '13

28 Jul '13

--001a11c3aa2ae1e46f04e28f422a Content-Type: text/plain; charset=ISO-8859-1 The log file did not show any errors. I ran the following: cd .../openldap-2.4.35/tests ksh -x ./run test060 The output (tail) is: + ./scripts/test060-mt-hot running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.35/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.35/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! + RC=1 + test no = yes + [ 1 -ne 0 ] + [ 1 -gt 1 ] + exit 1 The log file does not appear to have anything exciting (except the lack of a config file, and slow performance expected...) 51f4e855 @(#) $OpenLDAP: slapd 2.4.35 (Jul 22 2013 17:26:48) $ root@x094:/data/prj/openldap-2.4.35/servers/slapd 51f4e855 bdb_db_open: warning - no DB_CONFIG file found in directory /data/prj/openldap-2.4.35/tests/testrun/db.1.a: (2). Expect poor performance for suffix "dc=example,dc=com". 51f4e855 slapd starting 51f4e856 conn=1000 fd=13 ACCEPT from IP=127.0.0.1:36278 (IP=127.0.0.1:9011) 51f4e856 conn=1000 op=0 BIND dn="" method=128 51f4e856 conn=1000 op=0 RESULT tag=97 err=0 text= 51f4e856 conn=1000 op=1 SRCH base="cn=Monitor" scope=0 deref=0 filter="(objectClass=*)" 51f4e856 conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 51f4e856 conn=1000 op=2 UNBIND 51f4e856 conn=1000 fd=13 closed 51f4e856 conn=1001 fd=13 ACCEPT from IP=127.0.0.1:36279 (IP=127.0.0.1:9011) 51f4e856 conn=1001 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 51f4e856 conn=1001 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 51f4e856 conn=1001 op=0 RESULT tag=97 err=0 text= 51f4e856 conn=1001 op=1 SRCH base="cn=Monitor" scope=2 deref=0 filter="(objectClass=*)" 51f4e856 conn=1001 op=1 SRCH attr=1.1 51f4e856 conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=61 text= 51f4e856 conn=1001 op=2 SRCH base="cn=Monitor" scope=0 deref=0 filter="(objectClass=*)" 51f4e856 conn=1001 op=2 SRCH attr=1.1 51f4e856 conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= .... 51f4e8b0 conn=1003 op=31814 SEARCH RESULT tag=101 err=0 nentries=1 text= 51f4e8b0 conn=1003 op=31815 SRCH base="cn=Tasklist,cn=Threads,cn=Monitor" scope=0 deref=0 filter="(objectClass=*)" 51f4e8b0 conn=1003 op=31815 SRCH attr=1.1 51f4e8b0 conn=1003 op=31815 SEARCH RESULT tag=101 err=0 nentries=1 text= 51f4e8b0 conn=1003 op=31816 UNBIND 51f4e8b0 conn=1003 fd=13 closed 51f4e8b0 daemon: shutdown requested and initiated. 51f4e8b0 slapd shutdown: waiting for 0 operations/tasks to finish 51f4e8b0 slapd stopped. Next hint please! Michael On Sat, Jul 27, 2013 at 7:10 PM, Howard Chu <hyc(a)symas.com> wrote: > mamfelt(a)gmail.com wrote: > >> --089e0160a454490f9304e28133c7 >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> p.s. what is the quick way to run this test directly, rather than 1-59 >> before running test 60? >> > > <openldap>/tests/run test060 > > > I did not find a core dump. >> > > Read the tail end of testrun/slapd.1.log and look for any error messages. > > > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --001a11c3aa2ae1e46f04e28f422a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The log file did not show any errors. I ran the following: cd= .../openldap-2.4.35/tests ksh -x ./run test060 The output (tail)= is: + ./scripts/test0= 60-mt-hot running defines.sh Running slapadd to build slapd database... Running= slapindex to index slapd database... Starting slapd on TCP/IP port 9011= ... /data/prj/openldap-2.4.35/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.35/tests/testrun/slapd.1.conf -h=20 ldap://localhost:9011/ -d stats Testing basic monitor search... Monit= or searches Testing basic mt-hot search: 1 threads (1 x 50000) loops...<= br>./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexam= ple,dc=3Dcom -w secret -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slap= d-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample,dc=3Dcom -w= secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: = 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread fail= ed (1)! + RC=3D1 + test no =3D yes + [ 1 -ne 0 ] + [ 1 -gt 1 ]<= br>+ exit 1 The log file does not appear to have anything exciting (except t= he lack of a config file, and slow performance expected...) 51f4e855= @(#) $OpenLDAP: slapd 2.4.35 (Jul 22 2013 17:26:48) $ =A0=A0=A0=A0=A0= =A0=A0 root@x094:/data/prj/openldap-2.4.35/servers/slapd 51f4e855 bdb_db_open: warning - no DB_CONFIG file found in directory /data/= prj/openldap-2.4.35/tests/testrun/db.1.a: (2). Expect poor performance f= or suffix "dc=3Dexample,dc=3Dcom". 51f4e855 slapd starting 51f4e856 conn=3D1000 fd=3D13 ACCEPT from IP=3D<a href=3D"http://127.0.0.1:3= 6278">127.0.0.1:36278</a> (IP=3D<a href=3D"http://127.0.0.1:9011">127.0.0.1= :9011</a>) 51f4e856 conn=3D1000 op=3D0 BIND dn=3D"" method=3D1= 28 51f4e856 conn=3D1000 op=3D0 RESULT tag=3D97 err=3D0 text=3D 51f4e856 conn=3D1000 op=3D1 SRCH base=3D"cn=3DMonitor" scope=3D0 = deref=3D0 filter=3D"(objectClass=3D*)" 51f4e856 conn=3D1000 op= =3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D 51f4e856 conn= =3D1000 op=3D2 UNBIND 51f4e856 conn=3D1000 fd=3D13 closed 51f4e856 conn=3D1001 fd=3D13 ACCEPT from IP=3D<a href=3D"http://127.0.0.1:3= 6279">127.0.0.1:36279</a> (IP=3D<a href=3D"http://127.0.0.1:9011">127.0.0.1= :9011</a>) 51f4e856 conn=3D1001 op=3D0 BIND dn=3D"cn=3DManager,dc= =3Dexample,dc=3Dcom" method=3D128 51f4e856 conn=3D1001 op=3D0 BIND dn=3D"cn=3DManager,dc=3Dexample,dc=3D= com" mech=3DSIMPLE ssf=3D0 51f4e856 conn=3D1001 op=3D0 RESULT tag= =3D97 err=3D0 text=3D 51f4e856 conn=3D1001 op=3D1 SRCH base=3D"cn= =3DMonitor" scope=3D2 deref=3D0 filter=3D"(objectClass=3D*)"= 51f4e856 conn=3D1001 op=3D1 SRCH attr=3D1.1 51f4e856 conn=3D1001 op=3D1 = SEARCH RESULT tag=3D101 err=3D0 nentries=3D61 text=3D 51f4e856 conn=3D10= 01 op=3D2 SRCH base=3D"cn=3DMonitor" scope=3D0 deref=3D0 filter= =3D"(objectClass=3D*)" 51f4e856 conn=3D1001 op=3D2 SRCH attr=3D1.1 51f4e856 conn=3D1001 op=3D2 = SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D .... 51f4e8b0 co= nn=3D1003 op=3D31814 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D<b= r>51f4e8b0 conn=3D1003 op=3D31815 SRCH base=3D"cn=3DTasklist,cn=3DThre= ads,cn=3DMonitor" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)= " 51f4e8b0 conn=3D1003 op=3D31815 SRCH attr=3D1.1 51f4e8b0 conn=3D1003 op= =3D31815 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D 51f4e8b0 c= onn=3D1003 op=3D31816 UNBIND 51f4e8b0 conn=3D1003 fd=3D13 closed 51f4= e8b0 daemon: shutdown requested and initiated. 51f4e8b0 slapd shutdown: waiting for 0 operations/tasks to finish 51f4e8= b0 slapd stopped. Next hint please! Michael <div class= =3D"gmail_quote">On Sat, Jul 27, 2013 at 7:10 PM, Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a= >> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:mamfelt@gmail.com" target= =3D"_blank">mamfelt(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --089e0160a454490f9304e28133c7 Content-Type: text/plain; charset=3DISO-8859-1<div class=3D"im"> p.s. what is the quick way to run this test directly, rather than 1-59 before running test 60? </div></blockquote> <openldap>/tests/run test060<div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I did not find a core dump. </blockquote> </div> Read the tail end of testrun/slapd.1.log and look for any error messages.<d= iv class=3D"HOEnZb"><div class=3D"h5"> =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> --001a11c3aa2ae1e46f04e28f422a--

1 0

Fwd: Re: (ITS#7644) inverted MDB_SET_RANGE desired
by hyc＠symas.com 27 Jul '13

27 Jul '13

-------- Original Message -------- Subject: Re: (ITS#7644) inverted MDB_SET_RANGE desired Date: Sat, 27 Jul 2013 14:26:51 -0700 From: Howard Chu <hyc(a)symas.com> To: Michiel Visser <vissermc(a)gmail.com> Michiel Visser wrote: > Dear Mr Chu, > > Answering your question: in case the found key is equal, you could specify: > the key parameter *must* stay the untouched (same mv_data pointer), thus no > extra memory block will be allocated that is basically a duplicate. Maybe it > is already implemented this way? Important is that this should be documented > (such that it is frozen). This would make it possible to have my desired > functionality (and more) without sacrificing any performance (doing another > unnecessary key comparison). > > By the way: the documentation does not tell whether the input key memory > (mv_data) will stay untouched, in case the output key is different (but its > size the same or smaller), or that always new memory is allocated for this > purpose. 1) the library *never* allocates memory to return a value to you. I thought that was already stated clearly. That's one of the fundamental design principles of LMDB. You should know this already if you've read the docs. 2) The mdb_cursor_get() doc states explicitly that the object's address is returned *except* in the case of MDB_SET. I'm not sure it would be wise to change this at this point in time, people have been using LMDB for going on 2 years already. > Thank you for your time, and I want to make clear I really like mdb, and its > interface :) > > Michiel Visser > > > 2013/7/24 Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> > > vissermc(a)gmail.com <mailto:vissermc@gmail.com> wrote: > > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/__incoming/ <ftp://ftp.openldap.org/incoming/> > Submission from: (NULL) (88.159.211.22) > > > Feature request: > MDB_SET_RANGE is an important option for me (I'm implementing a > generic triple > store on top of MDB). But I also desire some additions: > 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In > theory I could > also apply an inverted compare function, but this makes it > counter-intuitive > ('bigger' actually implying 'smaller'). And I understand I can also use > SET_RANGE, followed by a cursor-previous-traversal, but it would > require extra > logic to check whether the key is already equal, which brings me to my > second > point: > > > Extra logic will be required anyway, whether inside liblmdb or in your > application. In this case I don't see value in making the library bigger > to handle this. > > 2) a way to see whether the returned key is equal (to the supplied > key), to > avoid another call to get/cursor_get, or avoid a manual key compare. > > > The mdb_cursor_get() function signature is what it is, there's nowhere to > return any other parameters. How would you propose to indicate this to the > caller? > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#7642) make test for AIX fails on test060-mt-hot
by hyc＠symas.com 27 Jul '13

27 Jul '13

mamfelt(a)gmail.com wrote: > --089e0160a454490f9304e28133c7 > Content-Type: text/plain; charset=ISO-8859-1 > > p.s. what is the quick way to run this test directly, rather than 1-59 > before running test 60? <openldap>/tests/run test060 > I did not find a core dump. Read the tail end of testrun/slapd.1.log and look for any error messages. -- 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#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 27 Jul '13

27 Jul '13

--089e0149421a38e87104e281384b Content-Type: text/plain; charset=ISO-8859-1 And the ulimit values on the test system are: root@x094:[/data/prj/openldap-2.4.35]ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 4194304 memory(kbytes) unlimited coredump(blocks) unlimited nofiles(descriptors) 2000 threads(per process) unlimited processes(per user) unlimited On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <hyc(a)symas.com> wrote: > mamfelt(a)gmail.com wrote: > >> Full_Name: Michael Felt >> Version: 2.4.32 >> OS: AIX 6.1 TL7 >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (81.253.45.94) >> >> >> built bdb 6.0.20 >> built openLDAP 2.4.32 using xlC v11 >> > > Current is 2.4.35, you should have built latest. > > make test runs fine, then stops abruptly at test060 >> > > No ideas offhand, but possibly running into a default file descriptor > limit or some other ulimit issue. Check that first. I don't believe there's > any actual software bug here but it's been a long time since I've built on > AIX. > > extract of failing test... >> >> >> Starting test060-mt-hot for bdb... >>>>>>> >>>>>> running defines.sh >> Running slapadd to build slapd database... >> Running slapindex to index slapd database... >> Starting slapd on TCP/IP port 9011... >> /data/prj/openldap-2.4.32/**tests/../servers/slapd/slapd -s0 -f >> /data/prj/openldap-2.4.32/**tests/testrun/slapd.1.conf -h >> ldap://localhost:9011/ >> -d stats >> Testing basic monitor search... >> Monitor searches >> Testing basic mt-hot search: 1 threads (1 x 50000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 1 -L 1 -l 50000 >> Testing basic mt-hot search: 5 threads (1 x 10000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 5 -L 1 -l 10000 >> Testing basic mt-hot search: 100 threads (5 x 100) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 100 -L 5 -l 100 >> slapd-mtread failed (1)! >> >>> test060-mt-hot failed for bdb >>>>>>> >>>>>> (exit 1) >> make: 1254-004 The error code from the last command is 1. >> >> >> Stop. >> make: 1254-004 The error code from the last command is 2. >> >> >> Stop. >> make: 1254-004 The error code from the last command is 2. >> >> >> Stop. >> >> AIX Level Info: >> root@x094:[/data/prj/openldap-**2.4.32]oslevel -s >> 6100-07-06-1241 >> >> ############ >> Please excuse that I have no clue what this test means, or if it will >> stand in >> the way of some basic setup of openLDAP as a server. However, since I am >> asking, >> I am also promising to dig deeper with some assistance. >> >> p.s. if I should have used a bug submission elsewhere, please forgive my >> blindness. I did not find it first go around. >> >> Michael >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --089e0149421a38e87104e281384b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And the ulimit values on the test system are: root@x094:[/data/prj/openldap-2.4.35]ulimit -a t= ime(seconds)=A0=A0=A0=A0=A0=A0=A0 unlimited file(blocks)=A0=A0=A0=A0=A0= =A0=A0=A0 unlimited data(kbytes)=A0=A0=A0=A0=A0=A0=A0=A0 unlimited stack(kbytes)=A0=A0=A0=A0=A0=A0=A0 4194304 memory(kbytes)=A0=A0=A0=A0=A0= =A0 unlimited coredump(blocks)=A0=A0=A0=A0 unlimited nofiles(descript= ors) 2000 threads(per process) unlimited processes(per user)=A0 unlim= ited <div class=3D"gmail_quote"> On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <<a href= =3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> wr= ote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:mamfelt@gmail.com" target=3D"_blank">mamfelt(a)gmail.com</a= > wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Michael Felt Version: 2.4.32 OS: AIX 6.1 TL7 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (81.253.45.94) built bdb 6.0.20 built openLDAP 2.4.32 using xlC v11 </blockquote> Current is 2.4.35, you should have built latest. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> make test runs fine, then stops abruptly at test060 </blockquote> No ideas offhand, but possibly running into a default file descriptor limit= or some other ulimit issue. Check that first. I don't believe there&#3= 9;s any actual software bug here but it's been a long time since I'= ve built on AIX. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> extract of failing test... <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Starting test060-mt-hot for bdb... </blockquote></blockquote></blockquote></blockquote></blockquote> running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://local= host:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> test060-mt-hot failed for bdb </blockquote></blockquote></blockquote></blockquote></blockquote> (exit 1) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. AIX Level Info: root@x094:[/data/prj/openldap-2.4.32]oslevel -s 6100-07-06-1241 ############ Please excuse that I have no clue what this test means, or if it will stand= in the way of some basic setup of openLDAP as a server. However, since I am as= king, I am also promising to dig deeper with some assistance. p.s. if I should have used a bug submission elsewhere, please forgive my<br= > blindness. I did not find it first go around. Michael </blockquote> -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --089e0149421a38e87104e281384b--

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 27 Jul '13

27 Jul '13

--089e0160a454490f9304e28133c7 Content-Type: text/plain; charset=ISO-8859-1 p.s. what is the quick way to run this test directly, rather than 1-59 before running test 60? I did not find a core dump. On Sat, Jul 27, 2013 at 6:58 PM, Michael Felt <mamfelt(a)gmail.com> wrote: > reply to all this time. > > 1) also did .35 version, same message > 2) these, except for filesize, are the defaults for at least the last 10 > years: > time(seconds) unlimited > file(blocks) unlimited > data(kbytes) 131072 > stack(kbytes) 32768 > memory(kbytes) 32768 > coredump(blocks) 2097151 > nofiles(descriptors) 2000 > > Now, it is perhaps possible that the data/memory/ and/or stack size is too > small. I shall check on the test system to see if the defaults are the same > as above, or if all have been reset. > I'll even look for a coredump to see if it says anything more about what > has happened. > > Thanks for the reply! > > Michael > > On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <hyc(a)symas.com> wrote: > >> mamfelt(a)gmail.com wrote: >> >>> Full_Name: Michael Felt >>> Version: 2.4.32 >>> OS: AIX 6.1 TL7 >>> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >>> Submission from: (NULL) (81.253.45.94) >>> >>> >>> built bdb 6.0.20 >>> built openLDAP 2.4.32 using xlC v11 >>> >> >> Current is 2.4.35, you should have built latest. >> >> make test runs fine, then stops abruptly at test060 >>> >> >> No ideas offhand, but possibly running into a default file descriptor >> limit or some other ulimit issue. Check that first. I don't believe there's >> any actual software bug here but it's been a long time since I've built on >> AIX. >> >> extract of failing test... >>> >>> >>> Starting test060-mt-hot for bdb... >>>>>>>> >>>>>>> running defines.sh >>> Running slapadd to build slapd database... >>> Running slapindex to index slapd database... >>> Starting slapd on TCP/IP port 9011... >>> /data/prj/openldap-2.4.32/**tests/../servers/slapd/slapd -s0 -f >>> /data/prj/openldap-2.4.32/**tests/testrun/slapd.1.conf -h >>> ldap://localhost:9011/ >>> -d stats >>> Testing basic monitor search... >>> Monitor searches >>> Testing basic mt-hot search: 1 threads (1 x 50000) loops... >>> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >>> cn=Manager,dc=example,dc=com >>> -w secret -e cn=Monitor -m 1 -L 1 -l 50000 >>> Testing basic mt-hot search: 5 threads (1 x 10000) loops... >>> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >>> cn=Manager,dc=example,dc=com >>> -w secret -e cn=Monitor -m 5 -L 1 -l 10000 >>> Testing basic mt-hot search: 100 threads (5 x 100) loops... >>> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >>> cn=Manager,dc=example,dc=com >>> -w secret -e cn=Monitor -m 100 -L 5 -l 100 >>> slapd-mtread failed (1)! >>> >>>> test060-mt-hot failed for bdb >>>>>>>> >>>>>>> (exit 1) >>> make: 1254-004 The error code from the last command is 1. >>> >>> >>> Stop. >>> make: 1254-004 The error code from the last command is 2. >>> >>> >>> Stop. >>> make: 1254-004 The error code from the last command is 2. >>> >>> >>> Stop. >>> >>> AIX Level Info: >>> root@x094:[/data/prj/openldap-**2.4.32]oslevel -s >>> 6100-07-06-1241 >>> >>> ############ >>> Please excuse that I have no clue what this test means, or if it will >>> stand in >>> the way of some basic setup of openLDAP as a server. However, since I am >>> asking, >>> I am also promising to dig deeper with some assistance. >>> >>> p.s. if I should have used a bug submission elsewhere, please forgive my >>> blindness. I did not find it first go around. >>> >>> Michael >>> >>> >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> >> > > --089e0160a454490f9304e28133c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable p.s. what is the quick way to run this test directly, rather than 1-59 befo= re running test 60? I did not find a core dump. <div class=3D= "gmail_quote">On Sat, Jul 27, 2013 at 6:58 PM, Michael Felt <<a href=3D"mailto:mamfelt@gmail.com" target=3D"_blank">mamfelt@gmail= .com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">reply to all this time. 1) also did .= 35 version, same message 2) these, except for filesize, are the defaults= for at least the last 10 years: time(seconds)=A0=A0=A0=A0=A0=A0=A0 unlimited file(blocks)=A0=A0=A0=A0=A0= =A0=A0=A0 unlimited data(kbytes)=A0=A0=A0=A0=A0=A0=A0=A0 131072 stack(kbytes)=A0=A0=A0=A0=A0= =A0=A0 32768 memory(kbytes)=A0=A0=A0=A0=A0=A0 32768 coredump(blocks)= =A0=A0=A0=A0 2097151 nofiles(descriptors) 2000 Now, it is perhaps= possible that the data/memory/ and/or stack size is too small. I shall che= ck on the test system to see if the defaults are the same as above, or if a= ll have been reset. I'll even look for a coredump to see if it says anything more about wha= t has happened. Thanks for the reply! Michael <div class=3D"gmail_qu= ote"> <div class=3D"im">On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com<= /a>> wrote: </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mail= to:mamfelt@gmail.com" target=3D"_blank">mamfelt(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Michael Felt Version: 2.4.32 OS: AIX 6.1 TL7 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (81.253.45.94) built bdb 6.0.20 built openLDAP 2.4.32 using xlC v11 </blockquote> Current is 2.4.35, you should have built latest. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> make test runs fine, then stops abruptly at test060 </blockquote> No ideas offhand, but possibly running into a default file descriptor limit= or some other ulimit issue. Check that first. I don't believe there&#3= 9;s any actual software bug here but it's been a long time since I'= ve built on AIX. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> extract of failing test... <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Starting test060-mt-hot for bdb... </blockquote></blockquote></blockquote></blockquote></blockquote> running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://local= host:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> test060-mt-hot failed for bdb </blockquote></blockquote></blockquote></blockquote></blockquote> (exit 1) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. AIX Level Info: root@x094:[/data/prj/openldap-2.4.32]oslevel -s 6100-07-06-1241 ############ Please excuse that I have no clue what this test means, or if it will stand= in the way of some basic setup of openLDAP as a server. However, since I am as= king, I am also promising to dig deeper with some assistance. p.s. if I should have used a bug submission elsewhere, please forgive my<br= > blindness. I did not find it first go around. Michael </blockquote> -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div></div></div> </blockquote></div> --089e0160a454490f9304e28133c7--

1 0

Re: (ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 27 Jul '13

27 Jul '13

--001a11c37b0ad47a1804e2812bc0 Content-Type: text/plain; charset=ISO-8859-1 reply to all this time. 1) also did .35 version, same message 2) these, except for filesize, are the defaults for at least the last 10 years: time(seconds) unlimited file(blocks) unlimited data(kbytes) 131072 stack(kbytes) 32768 memory(kbytes) 32768 coredump(blocks) 2097151 nofiles(descriptors) 2000 Now, it is perhaps possible that the data/memory/ and/or stack size is too small. I shall check on the test system to see if the defaults are the same as above, or if all have been reset. I'll even look for a coredump to see if it says anything more about what has happened. Thanks for the reply! Michael On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <hyc(a)symas.com> wrote: > mamfelt(a)gmail.com wrote: > >> Full_Name: Michael Felt >> Version: 2.4.32 >> OS: AIX 6.1 TL7 >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (81.253.45.94) >> >> >> built bdb 6.0.20 >> built openLDAP 2.4.32 using xlC v11 >> > > Current is 2.4.35, you should have built latest. > > make test runs fine, then stops abruptly at test060 >> > > No ideas offhand, but possibly running into a default file descriptor > limit or some other ulimit issue. Check that first. I don't believe there's > any actual software bug here but it's been a long time since I've built on > AIX. > > extract of failing test... >> >> >> Starting test060-mt-hot for bdb... >>>>>>> >>>>>> running defines.sh >> Running slapadd to build slapd database... >> Running slapindex to index slapd database... >> Starting slapd on TCP/IP port 9011... >> /data/prj/openldap-2.4.32/**tests/../servers/slapd/slapd -s0 -f >> /data/prj/openldap-2.4.32/**tests/testrun/slapd.1.conf -h >> ldap://localhost:9011/ >> -d stats >> Testing basic monitor search... >> Monitor searches >> Testing basic mt-hot search: 1 threads (1 x 50000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 1 -L 1 -l 50000 >> Testing basic mt-hot search: 5 threads (1 x 10000) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 5 -L 1 -l 10000 >> Testing basic mt-hot search: 100 threads (5 x 100) loops... >> ./progs/slapd-mtread -H ldap://localhost:9011/ -D >> cn=Manager,dc=example,dc=com >> -w secret -e cn=Monitor -m 100 -L 5 -l 100 >> slapd-mtread failed (1)! >> >>> test060-mt-hot failed for bdb >>>>>>> >>>>>> (exit 1) >> make: 1254-004 The error code from the last command is 1. >> >> >> Stop. >> make: 1254-004 The error code from the last command is 2. >> >> >> Stop. >> make: 1254-004 The error code from the last command is 2. >> >> >> Stop. >> >> AIX Level Info: >> root@x094:[/data/prj/openldap-**2.4.32]oslevel -s >> 6100-07-06-1241 >> >> ############ >> Please excuse that I have no clue what this test means, or if it will >> stand in >> the way of some basic setup of openLDAP as a server. However, since I am >> asking, >> I am also promising to dig deeper with some assistance. >> >> p.s. if I should have used a bug submission elsewhere, please forgive my >> blindness. I did not find it first go around. >> >> Michael >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --001a11c37b0ad47a1804e2812bc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable reply to all this time. 1) also did .35 version, same message 2) = these, except for filesize, are the defaults for at least the last 10 years= : time(seconds)=A0=A0=A0=A0=A0=A0=A0 unlimited file(blocks)=A0=A0=A0= =A0=A0=A0=A0=A0 unlimited data(kbytes)=A0=A0=A0=A0=A0=A0=A0=A0 131072 stack(kbytes)=A0=A0=A0=A0=A0= =A0=A0 32768 memory(kbytes)=A0=A0=A0=A0=A0=A0 32768 coredump(blocks)= =A0=A0=A0=A0 2097151 nofiles(descriptors) 2000 Now, it is perhaps= possible that the data/memory/ and/or stack size is too small. I shall che= ck on the test system to see if the defaults are the same as above, or if a= ll have been reset. I'll even look for a coredump to see if it says anything more about wha= t has happened. Thanks for the reply! Michael <div cla= ss=3D"gmail_quote">On Fri, Jul 26, 2013 at 10:11 PM, Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.c= om</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:mamfelt@gmail.com" target= =3D"_blank">mamfelt(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Michael Felt Version: 2.4.32 OS: AIX 6.1 TL7 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (81.253.45.94) built bdb 6.0.20 built openLDAP 2.4.32 using xlC v11 </blockquote> Current is 2.4.35, you should have built latest. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> make test runs fine, then stops abruptly at test060 </blockquote> No ideas offhand, but possibly running into a default file descriptor limit= or some other ulimit issue. Check that first. I don't believe there&#3= 9;s any actual software bug here but it's been a long time since I'= ve built on AIX. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> extract of failing test... <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Starting test060-mt-hot for bdb... </blockquote></blockquote></blockquote></blockquote></blockquote> running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://local= host:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=3DManager,dc=3Dexample= ,dc=3Dcom -w secret -e cn=3DMonitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> test060-mt-hot failed for bdb </blockquote></blockquote></blockquote></blockquote></blockquote> (exit 1) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. AIX Level Info: root@x094:[/data/prj/openldap-2.4.32]oslevel -s 6100-07-06-1241 ############ Please excuse that I have no clue what this test means, or if it will stand= in the way of some basic setup of openLDAP as a server. However, since I am as= king, I am also promising to dig deeper with some assistance. p.s. if I should have used a bug submission elsewhere, please forgive my<br= > blindness. I did not find it first go around. Michael </blockquote> -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --001a11c37b0ad47a1804e2812bc0--

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by hyc＠symas.com 26 Jul '13

26 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: > Full_Name: Timothy Pearson > Version: 2.4.35 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.156.2.26) > > > slapd sporadically crashes in slapd_free_controls when syncrepl enabled and > plugins are in use. The crash is caused by an invalid free in the slapi > overlay; it only occurs on the provider in a syncrepl setup. This is the > backtrace: > > This patch fixes the problem: Looks good, thanks. Committed to master. > --- servers/slapd/slapi/slapi_overlay.c > +++ servers/slapd/slapi/slapi_overlay.c > @@ -454,11 +454,11 @@ > n_slapi_ctrls = slapi_int_count_controls( slapi_ctrls ); > n_rs_ctrls = slapi_int_count_controls( rs->sr_ctrls ); > > - slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); > - > if ( n_slapi_ctrls == 0 ) > return LDAP_SUCCESS; /* no SLAPI controls */ > > + slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); > + > ctrls = (LDAPControl **) op->o_tmpalloc( > ( n_slapi_ctrls + n_rs_ctrls + 1 ) * sizeof(LDAPControl *), > op->o_tmpmemctx ); > > -- -- 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#7642) make test for AIX fails on test060-mt-hot
by hyc＠symas.com 26 Jul '13

26 Jul '13

mamfelt(a)gmail.com wrote: > Full_Name: Michael Felt > Version: 2.4.32 > OS: AIX 6.1 TL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.253.45.94) > > > built bdb 6.0.20 > built openLDAP 2.4.32 using xlC v11 Current is 2.4.35, you should have built latest. > make test runs fine, then stops abruptly at test060 No ideas offhand, but possibly running into a default file descriptor limit or some other ulimit issue. Check that first. I don't believe there's any actual software bug here but it's been a long time since I've built on AIX. > extract of failing test... > > >>>>>> Starting test060-mt-hot for bdb... > running defines.sh > Running slapadd to build slapd database... > Running slapindex to index slapd database... > Starting slapd on TCP/IP port 9011... > /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f > /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ > -d stats > Testing basic monitor search... > Monitor searches > Testing basic mt-hot search: 1 threads (1 x 50000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 1 -L 1 -l 50000 > Testing basic mt-hot search: 5 threads (1 x 10000) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 5 -L 1 -l 10000 > Testing basic mt-hot search: 100 threads (5 x 100) loops... > ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com > -w secret -e cn=Monitor -m 100 -L 5 -l 100 > slapd-mtread failed (1)! >>>>>> test060-mt-hot failed for bdb > (exit 1) > make: 1254-004 The error code from the last command is 1. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > > AIX Level Info: > root@x094:[/data/prj/openldap-2.4.32]oslevel -s > 6100-07-06-1241 > > ############ > Please excuse that I have no clue what this test means, or if it will stand in > the way of some basic setup of openLDAP as a server. However, since I am asking, > I am also promising to dig deeper with some assistance. > > p.s. if I should have used a bug submission elsewhere, please forgive my > blindness. I did not find it first go around. > > Michael > > -- -- 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#7648) undefined symbol: ldap_x_utf8s_to_wcs
by hyc＠symas.com 26 Jul '13

26 Jul '13

msquaredm(a)yahoo.com wrote: > Full_Name: Mike > Version: 2.4.35 > OS: Cent0s v6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.51.198.154) > > > Hi, > > I've compiled v2.4.35 with the smbk5pwd overlay. When I change my password the > openldap terminates with the message: > > /usr/sbin/slapd: symbol lookup error: /usr/lib64/openldap/smbk5pwd-2.4.so.2: > undefined symbol: ldap_x_utf8s_to_wcs > > Thanks for any help. The ITS is for actual bug reports, not requests for help. Use the openldap-technical mailing list. Closing this ITS. -- -- 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#7650) Multi-master replication deadlock with TLS
by hyc＠symas.com 26 Jul '13

26 Jul '13

sdj42(a)live.com wrote: > Full_Name: Scott Ireland > Version: 2.4.23 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.34.120.71) > > > A 2-server, multi-master replication setup appears to deadlock during sync. > After a period of time (sometimes hours), both servers will lock up at the same > time and fail to handle requests (although they do accept TCP connections). > This only occurs when the sync occurs with TLS (either StartTLS or ldaps); when > TLS is not used the sync runs without incident. Stopping/restarting one of the > servers clears the lockup on the other server. Sometimes the issue can be > triggered immediately when a change is made to the database (in which case the > client does not see the operation complete), but will also occur on its own as > periodic replication checks occur. You're running a very old release, current is 2.4.35. You're running a Red Hat customized build, contact Red Hat for support. Closing this ITS. > Typical log (level 0x4100) before the freeze: > > Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 fd=23 ACCEPT from > IP=redacted:48388 (IP=redacted:389) > Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 STARTTLS > Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 RESULT oid= err=0 text= > [freezes here] > > GDB backtrace (this lock was triggered by a change in cn=config): > > (gdb) info threads > 5 Thread 0x7f7eeb3d0700 (LWP 7048) 0x00007f7eee227f03 in epoll_wait () > from /lib64/libc.so.6 > 4 Thread 0x7f7ed5028700 (LWP 7049) 0x00007f7eee6eb054 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 3 Thread 0x7f7ed4827700 (LWP 7050) 0x00007f7eee6eb54d in read () > from /lib64/libpthread.so.0 > 2 Thread 0x7f7ecffff700 (LWP 7051) 0x00007f7eee6e843c in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7f7ef0700700 (LWP 7043) 0x00007f7eee6e50ad in pthread_join () > from /lib64/libpthread.so.0 > > (gdb) bt > #0 0x00007f7eee6e50ad in pthread_join () from /lib64/libpthread.so.0 > #1 0x00007f7ef075685c in slapd_daemon () > at ../../../servers/slapd/daemon.c:2842 > #2 0x00007f7ef0742b0e in main (argc=5, argv=<value optimized out>) > at ../../../servers/slapd/main.c:961 > > (gdb) thread 2 > [Switching to thread 2 (Thread 0x7f7ecffff700 (LWP 7051))]#0 0x00007f7eee6e843c > in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f7eee6e843c in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00007f7ef085c6fb in handle_pause (tpool=<value optimized out>, > do_pause=1) at ../../../libraries/libldap_r/tpool.c:757 > #2 0x00007f7ef074a53c in config_back_modify (op=0x7f7ec81adaa0, > rs=0x7f7ecfffe920) at ../../../servers/slapd/bconfig.c:5677 > #3 0x00007f7ef07c8977 in overlay_op_walk (op=0x7f7ec81adaa0, > rs=0x7f7ecfffe920, which=op_modify, oi=0x7f7ef1a644c0, on=0x0) > at ../../../servers/slapd/backover.c:669 > #4 0x00007f7ef07c93cb in over_op_func (op=0x7f7ec81adaa0, > rs=<value optimized out>, which=<value optimized out>) > at ../../../servers/slapd/backover.c:721 > #5 0x00007f7ef0775ece in fe_op_modify (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920) > at ../../../servers/slapd/modify.c:301 > #6 0x00007f7ef077685c in do_modify (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920) > at ../../../servers/slapd/modify.c:175 > #7 0x00007f7ef075c9f9 in connection_operation (ctx=0x7f7ecfffeb70, > arg_v=0x7f7ec81adaa0) at ../../../servers/slapd/connection.c:1109 > #8 0x00007f7ef075d34d in connection_read_thread (ctx=0x7f7ecfffeb70, > argv=<value optimized out>) at ../../../servers/slapd/connection.c:1245 > #9 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) > at ../../../libraries/libldap_r/tpool.c:685 > #10 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 > #11 0x00007f7eee22790d in clone () from /lib64/libc.so.6 > > (gdb) thread 3 > [Switching to thread 3 (Thread 0x7f7ed4827700 (LWP 7050))]#0 0x00007f7eee6eb54d > in read () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f7eee6eb54d in read () from /lib64/libpthread.so.0 > #1 0x00007f7ef088c67c in sb_debug_read (sbiod=0x7f7ec0174cb0, > buf=0x7f7ec0191130, len=5) at ../../../libraries/liblber/sockbuf.c:829 > #2 0x00007f7ef0882564 in tlsm_PR_Recv (fd=<value optimized out>, > buf=0x7f7ec0191130, len=5, flags=<value optimized out>, > timeout=<value optimized out>) at tls_m.c:3032 > #3 0x00007f7eef6ed1ed in ssl_DefRecv (ss=<value optimized out>, > buf=<value optimized out>, len=5, flags=<value optimized out>) > at ssldef.c:62 > #4 0x00007f7eef6e8480 in ssl3_GatherData (ss=0x7f7ec0190d50, flags=0) > at ssl3gthr.c:59 > #5 ssl3_GatherCompleteHandshake (ss=0x7f7ec0190d50, flags=0) at ssl3gthr.c:318 > #6 0x00007f7eef6eaed2 in ssl_GatherRecord1stHandshake (ss=0x7f7ec0190d50) > at sslcon.c:1227 > #7 0x00007f7eef6f1135 in ssl_Do1stHandshake (ss=0x7f7ec0190d50) > at sslsecur.c:120 > #8 0x00007f7eef6f296f in SSL_ForceHandshake (fd=<value optimized out>) > at sslsecur.c:390 > #9 0x00007f7ef0882288 in tlsm_session_accept_or_connect ( > session=0x7f7ec0174910, is_accept=<value optimized out>) at tls_m.c:2677 > #10 0x00007f7ef0880e8a in ldap_int_tls_connect (ld=0x7f7ec0107ca0, > conn=<value optimized out>, host=0x7f7ec0170710 "redacted") > at tls2.c:366 > #11 0x00007f7ef088110a in ldap_int_tls_start (ld=0x7f7ec0107ca0, > conn=0x7f7ec0107f10, srv=<value optimized out>) at tls2.c:845 > #12 0x00007f7ef088120e in ldap_start_tls_s (ld=0x7f7ec0107ca0, > serverctrls=0x0, clientctrls=0x0) at tls2.c:938 > #13 0x00007f7ef075269e in slap_client_connect (ldp=0x7f7ec01709f0, > sb=0x7f7ec01707d0) at ../../../servers/slapd/config.c:1921 > #14 0x00007f7ef07c5062 in do_syncrep1 (ctx=<value optimized out>, > arg=0x7f7ec0170b60) at ../../../servers/slapd/syncrepl.c:571 > #15 do_syncrepl (ctx=<value optimized out>, arg=0x7f7ec0170b60) > at ../../../servers/slapd/syncrepl.c:1422 > #16 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) > at ../../../libraries/libldap_r/tpool.c:685 > #17 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 > #18 0x00007f7eee22790d in clone () from /lib64/libc.so.6 > > (gdb) thread 4 > [Switching to thread 4 (Thread 0x7f7ed5028700 (LWP 7049))]#0 0x00007f7eee6eb054 > in __lll_lock_wait () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007f7eee6eb054 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f7eee6e6388 in _L_lock_854 () from /lib64/libpthread.so.0 > #2 0x00007f7eee6e6257 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x00007f7ef0882280 in tlsm_session_accept_or_connect ( > session=0x7f7ec4131df0, is_accept=<value optimized out>) at tls_m.c:2674 > #4 0x00007f7ef08812c7 in ldap_pvt_tls_accept (sb=0x7f7ec4140420, > ctx_arg=0x7f7ef1a82e70) at tls2.c:433 > #5 0x00007f7ef075d3bb in connection_read (ctx=0x7f7ed5027b70, argv=0x17) > at ../../../servers/slapd/connection.c:1326 > #6 connection_read_thread (ctx=0x7f7ed5027b70, argv=0x17) > at ../../../servers/slapd/connection.c:1238 > #7 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) > at ../../../libraries/libldap_r/tpool.c:685 > #8 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 > #9 0x00007f7eee22790d in clone () from /lib64/libc.so.6 > > (gdb) thread 5 > [Switching to thread 5 (Thread 0x7f7eeb3d0700 (LWP 7048))]#0 0x00007f7eee227f03 > in epoll_wait () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007f7eee227f03 in epoll_wait () from /lib64/libc.so.6 > #1 0x00007f7ef07576f5 in slapd_daemon_task (ptr=<value optimized out>) > at ../../../servers/slapd/daemon.c:2467 > #2 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 > #3 0x00007f7eee22790d in clone () from /lib64/libc.so.6 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7650) Multi-master replication deadlock with TLS
by quanah＠zimbra.com 26 Jul '13

26 Jul '13

--On Friday, July 26, 2013 7:54 PM +0000 sdj42(a)live.com wrote: > Full_Name: Scott Ireland > Version: 2.4.23 > OS: RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.34.120.71) 2.4.23 is years old. The build from RHEL is also known to be particularly bad because of the way they hacked NSS support into it, instead of sanely linking to OpenSSL. If you expect support on this issue, you need to talk to RedHat. I would suggest you use a modern version of OpenLDAP. If you are incapable of compiling it yourself, the packages from <http://ltb-project.org/wiki/download#openldap> are quite good. This ITS will be closed. If you can reproduce the problem on a *current* version of OpenLDAP linked to a *known good* TLS implementation, feel free to open a new report. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7650) Multi-master replication deadlock with TLS
by sdj42＠live.com 26 Jul '13

26 Jul '13

Full_Name: Scott Ireland Version: 2.4.23 OS: RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.34.120.71) A 2-server, multi-master replication setup appears to deadlock during sync. After a period of time (sometimes hours), both servers will lock up at the same time and fail to handle requests (although they do accept TCP connections). This only occurs when the sync occurs with TLS (either StartTLS or ldaps); when TLS is not used the sync runs without incident. Stopping/restarting one of the servers clears the lockup on the other server. Sometimes the issue can be triggered immediately when a change is made to the database (in which case the client does not see the operation complete), but will also occur on its own as periodic replication checks occur. Typical log (level 0x4100) before the freeze: Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 fd=23 ACCEPT from IP=redacted:48388 (IP=redacted:389) Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 STARTTLS Jul 25 11:09:43 cd1911-o99 slapd[5789]: conn=1380 op=0 RESULT oid= err=0 text= [freezes here] GDB backtrace (this lock was triggered by a change in cn=config): (gdb) info threads 5 Thread 0x7f7eeb3d0700 (LWP 7048) 0x00007f7eee227f03 in epoll_wait () from /lib64/libc.so.6 4 Thread 0x7f7ed5028700 (LWP 7049) 0x00007f7eee6eb054 in __lll_lock_wait () from /lib64/libpthread.so.0 3 Thread 0x7f7ed4827700 (LWP 7050) 0x00007f7eee6eb54d in read () from /lib64/libpthread.so.0 2 Thread 0x7f7ecffff700 (LWP 7051) 0x00007f7eee6e843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7f7ef0700700 (LWP 7043) 0x00007f7eee6e50ad in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f7eee6e50ad in pthread_join () from /lib64/libpthread.so.0 #1 0x00007f7ef075685c in slapd_daemon () at ../../../servers/slapd/daemon.c:2842 #2 0x00007f7ef0742b0e in main (argc=5, argv=<value optimized out>) at ../../../servers/slapd/main.c:961 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f7ecffff700 (LWP 7051))]#0 0x00007f7eee6e843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f7eee6e843c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f7ef085c6fb in handle_pause (tpool=<value optimized out>, do_pause=1) at ../../../libraries/libldap_r/tpool.c:757 #2 0x00007f7ef074a53c in config_back_modify (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920) at ../../../servers/slapd/bconfig.c:5677 #3 0x00007f7ef07c8977 in overlay_op_walk (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920, which=op_modify, oi=0x7f7ef1a644c0, on=0x0) at ../../../servers/slapd/backover.c:669 #4 0x00007f7ef07c93cb in over_op_func (op=0x7f7ec81adaa0, rs=<value optimized out>, which=<value optimized out>) at ../../../servers/slapd/backover.c:721 #5 0x00007f7ef0775ece in fe_op_modify (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920) at ../../../servers/slapd/modify.c:301 #6 0x00007f7ef077685c in do_modify (op=0x7f7ec81adaa0, rs=0x7f7ecfffe920) at ../../../servers/slapd/modify.c:175 #7 0x00007f7ef075c9f9 in connection_operation (ctx=0x7f7ecfffeb70, arg_v=0x7f7ec81adaa0) at ../../../servers/slapd/connection.c:1109 #8 0x00007f7ef075d34d in connection_read_thread (ctx=0x7f7ecfffeb70, argv=<value optimized out>) at ../../../servers/slapd/connection.c:1245 #9 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) at ../../../libraries/libldap_r/tpool.c:685 #10 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 #11 0x00007f7eee22790d in clone () from /lib64/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread 0x7f7ed4827700 (LWP 7050))]#0 0x00007f7eee6eb54d in read () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f7eee6eb54d in read () from /lib64/libpthread.so.0 #1 0x00007f7ef088c67c in sb_debug_read (sbiod=0x7f7ec0174cb0, buf=0x7f7ec0191130, len=5) at ../../../libraries/liblber/sockbuf.c:829 #2 0x00007f7ef0882564 in tlsm_PR_Recv (fd=<value optimized out>, buf=0x7f7ec0191130, len=5, flags=<value optimized out>, timeout=<value optimized out>) at tls_m.c:3032 #3 0x00007f7eef6ed1ed in ssl_DefRecv (ss=<value optimized out>, buf=<value optimized out>, len=5, flags=<value optimized out>) at ssldef.c:62 #4 0x00007f7eef6e8480 in ssl3_GatherData (ss=0x7f7ec0190d50, flags=0) at ssl3gthr.c:59 #5 ssl3_GatherCompleteHandshake (ss=0x7f7ec0190d50, flags=0) at ssl3gthr.c:318 #6 0x00007f7eef6eaed2 in ssl_GatherRecord1stHandshake (ss=0x7f7ec0190d50) at sslcon.c:1227 #7 0x00007f7eef6f1135 in ssl_Do1stHandshake (ss=0x7f7ec0190d50) at sslsecur.c:120 #8 0x00007f7eef6f296f in SSL_ForceHandshake (fd=<value optimized out>) at sslsecur.c:390 #9 0x00007f7ef0882288 in tlsm_session_accept_or_connect ( session=0x7f7ec0174910, is_accept=<value optimized out>) at tls_m.c:2677 #10 0x00007f7ef0880e8a in ldap_int_tls_connect (ld=0x7f7ec0107ca0, conn=<value optimized out>, host=0x7f7ec0170710 "redacted") at tls2.c:366 #11 0x00007f7ef088110a in ldap_int_tls_start (ld=0x7f7ec0107ca0, conn=0x7f7ec0107f10, srv=<value optimized out>) at tls2.c:845 #12 0x00007f7ef088120e in ldap_start_tls_s (ld=0x7f7ec0107ca0, serverctrls=0x0, clientctrls=0x0) at tls2.c:938 #13 0x00007f7ef075269e in slap_client_connect (ldp=0x7f7ec01709f0, sb=0x7f7ec01707d0) at ../../../servers/slapd/config.c:1921 #14 0x00007f7ef07c5062 in do_syncrep1 (ctx=<value optimized out>, arg=0x7f7ec0170b60) at ../../../servers/slapd/syncrepl.c:571 #15 do_syncrepl (ctx=<value optimized out>, arg=0x7f7ec0170b60) at ../../../servers/slapd/syncrepl.c:1422 #16 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) at ../../../libraries/libldap_r/tpool.c:685 #17 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 #18 0x00007f7eee22790d in clone () from /lib64/libc.so.6 (gdb) thread 4 [Switching to thread 4 (Thread 0x7f7ed5028700 (LWP 7049))]#0 0x00007f7eee6eb054 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f7eee6eb054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f7eee6e6388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007f7eee6e6257 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f7ef0882280 in tlsm_session_accept_or_connect ( session=0x7f7ec4131df0, is_accept=<value optimized out>) at tls_m.c:2674 #4 0x00007f7ef08812c7 in ldap_pvt_tls_accept (sb=0x7f7ec4140420, ctx_arg=0x7f7ef1a82e70) at tls2.c:433 #5 0x00007f7ef075d3bb in connection_read (ctx=0x7f7ed5027b70, argv=0x17) at ../../../servers/slapd/connection.c:1326 #6 connection_read_thread (ctx=0x7f7ed5027b70, argv=0x17) at ../../../servers/slapd/connection.c:1238 #7 0x00007f7ef085cdd8 in ldap_int_thread_pool_wrapper (xpool=0x7f7ef19957b0) at ../../../libraries/libldap_r/tpool.c:685 #8 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f7eee22790d in clone () from /lib64/libc.so.6 (gdb) thread 5 [Switching to thread 5 (Thread 0x7f7eeb3d0700 (LWP 7048))]#0 0x00007f7eee227f03 in epoll_wait () from /lib64/libc.so.6 (gdb) bt #0 0x00007f7eee227f03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007f7ef07576f5 in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2467 #2 0x00007f7eee6e4851 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f7eee22790d in clone () from /lib64/libc.so.6

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by hyc＠symas.com 26 Jul '13

26 Jul '13

This is a multi-part message in MIME format. --------------080809090905040609080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > jorge.perez.burgos(a)ericsson.com wrote: >> Hi, >> >> At the end, meta_back_op_result() will map inside the error returned by > ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, > nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no > retries. I think this happens too in add and delete. > > This explanation makes no sense, since meta_back_op_result is being called > with LDAP_BACK_SENDRESULT, which is SENDOK|SENDERR. > > The bug is definitely a problem, I can reproduce it running test036 repeatedly > on my laptop. Typically the test hangs within 5-10 iterations. This patch appears to fix the dropped result msg problem, but I haven't checked yet to see if it's now sending doubled result msgs somewhere else. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------080809090905040609080207 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/servers/slapd/back-meta/conn.c b/servers/slapd/back-meta/conn.c index 7e63fae..ab88028 100644 --- a/servers/slapd/back-meta/conn.c +++ b/servers/slapd/back-meta/conn.c @@ -787,10 +787,12 @@ meta_back_retry( LDAP_BACK_CONN_BINDING_CLEAR( msc ); } } - } + } +#if 0 /* don't send twice */ sendok &= ~LDAP_BACK_SENDERR; +#endif } if ( rc != LDAP_SUCCESS ) { --------------080809090905040609080207--

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by hyc＠symas.com 26 Jul '13

26 Jul '13

jorge.perez.burgos(a)ericsson.com wrote: > Hi, > > At the end, meta_back_op_result() will map inside the error returned by ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no retries. I think this happens too in add and delete. This explanation makes no sense, since meta_back_op_result is being called with LDAP_BACK_SENDRESULT, which is SENDOK|SENDERR. The bug is definitely a problem, I can reproduce it running test036 repeatedly on my laptop. Typically the test hangs within 5-10 iterations. > BR > > -----Original Message----- > From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] > Sent: lunes, 20 de mayo de 2013 21:41 > To: Jorge Perez Burgos > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#7591) back-meta modify operation not sending result to client > > On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: >> kludge fix for the problem >> >> --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 >> +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 >> @@ -176,6 +176,7 @@ >> } >> modv[ i ] = 0; >> >> + rs->sr_type = -1; >> retry:; >> ctrls = op->o_ctrls; >> rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ >> -198,6 +200,10 @@ >> } >> >> cleanup:; >> + if (rs->sr_type != REP_RESULT) { >> + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); >> + } >> + >> (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); >> >> if ( mdn.bv_val != op->o_req_dn.bv_val ) { > > Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. > > p. > -- -- 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#7615) NetBSD sem_open limited to 14 characters
by hyc＠symas.com 26 Jul '13

26 Jul '13

hyc(a)symas.com wrote: > Greg(a)Akua.com wrote: >> Full_Name: Greg Kerr >> Version: 2.4.35 >> OS: NetBSD & FreeBSD >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (50.88.130.68) >> >> >> MDB is not usable on NetBSD because mdb.c has >> >> sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); >> >> To create the semaphore name. >> >> This results in a 21 character name which is beyond the 14 allowed per "man >> sem_open" > > That's unfortunate. In Linux this limit is 251 characters. Seems you'd need to > use the btoa algorithm to safely fit a hash into this size limit. > > Pretty sure we've tested successfully on FreeBSD and MacOSX already, so > apparently they don't suffer from this same limit. mdb.master has been patched to use the btoa algorithm, which reduces our semaphore name length down to 15 chars. On NetBSD we additionally truncate the last to bring it down to 14. >> "less than 14 characters in length not including the terminating null >> character." >> >> I will make a local patch ... and maybe it's a NetBSD bug - or at least the >> package maintainers ... I will report to him. It's a NetBSD kernel limitation, which I verified here: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_sem.c?rev=1.40&conten… Seems like a stupid limit, but whatever. Also the doc wording is inaccurate, the name can actually be *up to* 14 chars. "Less than 14" to most English speakers means the length must be *less than* 14. I.e., 13 or shorter. But in fact 14 characters are allowed. If you're contacting the NetBSD maintainers already, please tell them their manpage is incorrect. -- -- 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#7649) Feature request: numSubordinates attribute
by michael＠stroeder.com 26 Jul '13

26 Jul '13

On Fri, 26 Jul 2013 15:03:41 GMT hyc(a)symas.com wrote > Need to think about this some more. While it's true that the back-hdb/mdb > backends already have this information and can easily provide it, it > introduces new security concerns that sysadmins would have to be aware of. > I.e., clients could use numsubordinates to discover the existence of entries > they are not permitted to access. Which means sysadmins would need to add new > ACLs specifically for controlling access to numsubordinates. > > If we just add the feature, and sysadmins aren't aware it was added, then > they have a security hole. True, but not really a new security consideration for an admin. We already have 'hasSubordinates' anyway. And for whatever new operational attribute introduced in former times the admin was considered responsible to restrict access by appropriate ACLs. I also find such an attribute to be very useful in some use-cases. Another aspect is how searches like (numSubordinates>=1) can be efficiently handled, e.g. in cases where most entries will have numSubordinates=0. Yes, I admit I use it for count-like searches where using no-op search control is too expensive. Ciao, Michael.

1 0

Re: (ITS#7649) Feature request: numSubordinates attribute
by ghenry＠OpenLDAP.org 26 Jul '13

26 Jul '13

> Need to think about this some more. While it's true that the back-hdb/mdb > backends already have this information and can easily provide it, it > introduces new security concerns that sysadmins would have to be aware of. > I.e., clients could use numsubordinates to discover the existence of entries > they are not permitted to access. Which means sysadmins would need to add > new ACLs specifically for controlling access to numsubordinates. > > If we just add the feature, and sysadmins aren't aware it was added, then > they have a security hole. That's very true. If it's an operational attribute wouldn't normal ACLs apply? For example if you are only permitted to see "self" in ou=Users, then you shouldn't be able to request numSubordinates on ou=Users or if you do you only see 1. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api

1 0

Re: (ITS#7649) Feature request: numSubordinates attribute
by hyc＠symas.com 26 Jul '13

26 Jul '13

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Dear all, > > It would be great if we supported a numSubordinates attribute so you can request > a count of the number of entries say at a base of > ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than > retrieve them all and count them up. I know there is a contrib noopsrch overlay > that others are using. > > The only reference I can see that other directories has is based on this: > > http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Need to think about this some more. While it's true that the back-hdb/mdb backends already have this information and can easily provide it, it introduces new security concerns that sysadmins would have to be aware of. I.e., clients could use numsubordinates to discover the existence of entries they are not permitted to access. Which means sysadmins would need to add new ACLs specifically for controlling access to numsubordinates. If we just add the feature, and sysadmins aren't aware it was added, then they have a security hole. -- -- 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#7649) Feature request: numSubordinates attribute
by ghenry＠OpenLDAP.org 26 Jul '13

26 Jul '13

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, It would be great if we supported a numSubordinates attribute so you can request a count of the number of entries say at a base of ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than retrieve them all and count them up. I know there is a contrib noopsrch overlay that others are using. The only reference I can see that other directories has is based on this: http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Thanks, Gavin.

1 0

(ITS#7648) undefined symbol: ldap_x_utf8s_to_wcs
by msquaredm＠yahoo.com 25 Jul '13

25 Jul '13

Full_Name: Mike Version: 2.4.35 OS: Cent0s v6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.51.198.154) Hi, I've compiled v2.4.35 with the smbk5pwd overlay. When I change my password the openldap terminates with the message: /usr/sbin/slapd: symbol lookup error: /usr/lib64/openldap/smbk5pwd-2.4.so.2: undefined symbol: ldap_x_utf8s_to_wcs Thanks for any help. Mike

1 0

(ITS#7645) various TLSProtocolMin issues
by mgaupp＠googlemail.com 24 Jul '13

24 Jul '13

Full_Name: Manuel Gaupp Version: 2.4.35 OS: CentOS 6.3 URL: Submission from: (NULL) (79.234.218.31) This topic was originally discussed in http://www.openldap.org/lists/openldap-technical/201307/msg00133.html 1.) the TLSProtocolMin parameter is not documented, but it should be - at least in slapd.conf/slapd-config and ldap.conf (there is an example in the original ITS #5655) 2.) the TLSProtocolMin functionality should be extended for TLS 1.1 and TLS 1.2 (see http://www.openldap.org/lists/openldap-technical/201307/msg00138.html) 3.) ldap.conf already accepts correctly formatted TLSProtocolMin values (e.g. "3.1") whereas slapd.conf doesn't (has to be given as an integer, e.g. "769"); I think servers/slapd/bconfig.c should be changed to use ldap_int_tls_config for this option (as mentioned in the FIXME comment of config_tls_config).

1 0

Re: (ITS#7643) MDB_cmp_func not properly documented
by hyc＠symas.com 23 Jul '13

23 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > The MDB documentation must specify what is expected of MDB_cmp_func. > I assume it must return -1,0,1 depending on the order, similar to ansi compare > functions, but it is not trivial, nor all will know. The mdb_cmp() description already describes the return values. Users of the library are expected to be able to associate related concepts. -- -- 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#7644) inverted MDB_SET_RANGE desired
by hyc＠symas.com 23 Jul '13

23 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > Feature request: > MDB_SET_RANGE is an important option for me (I'm implementing a generic triple > store on top of MDB). But I also desire some additions: > 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In theory I could > also apply an inverted compare function, but this makes it counter-intuitive > ('bigger' actually implying 'smaller'). And I understand I can also use > SET_RANGE, followed by a cursor-previous-traversal, but it would require extra > logic to check whether the key is already equal, which brings me to my second > point: Extra logic will be required anyway, whether inside liblmdb or in your application. In this case I don't see value in making the library bigger to handle this. > 2) a way to see whether the returned key is equal (to the supplied key), to > avoid another call to get/cursor_get, or avoid a manual key compare. The mdb_cursor_get() function signature is what it is, there's nowhere to return any other parameters. How would you propose to indicate this to the caller? -- -- 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#7644) inverted MDB_SET_RANGE desired
by vissermc＠gmail.com 23 Jul '13

23 Jul '13

Full_Name: Michiel Visser Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.159.211.22) Feature request: MDB_SET_RANGE is an important option for me (I'm implementing a generic triple store on top of MDB). But I also desire some additions: 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In theory I could also apply an inverted compare function, but this makes it counter-intuitive ('bigger' actually implying 'smaller'). And I understand I can also use SET_RANGE, followed by a cursor-previous-traversal, but it would require extra logic to check whether the key is already equal, which brings me to my second point: 2) a way to see whether the returned key is equal (to the supplied key), to avoid another call to get/cursor_get, or avoid a manual key compare.

1 0

(ITS#7643) MDB_cmp_func not properly documented
by vissermc＠gmail.com 23 Jul '13

23 Jul '13

Full_Name: Michiel Visser Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.159.211.22) The MDB documentation must specify what is expected of MDB_cmp_func. I assume it must return -1,0,1 depending on the order, similar to ansi compare functions, but it is not trivial, nor all will know.

1 0

(ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 22 Jul '13

22 Jul '13

Full_Name: Michael Felt Version: 2.4.32 OS: AIX 6.1 TL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.253.45.94) built bdb 6.0.20 built openLDAP 2.4.32 using xlC v11 make test runs fine, then stops abruptly at test060 extract of failing test... >>>>> Starting test060-mt-hot for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! >>>>> test060-mt-hot failed for bdb (exit 1) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. AIX Level Info: root@x094:[/data/prj/openldap-2.4.32]oslevel -s 6100-07-06-1241 ############ Please excuse that I have no clue what this test means, or if it will stand in the way of some basic setup of openLDAP as a server. However, since I am asking, I am also promising to dig deeper with some assistance. p.s. if I should have used a bug submission elsewhere, please forgive my blindness. I did not find it first go around. Michael

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by quanah＠zimbra.com 18 Jul '13

18 Jul '13

--On Thursday, July 18, 2013 9:15 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: >> --On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net > wrote: >> >>> Full_Name: Timothy Pearson >>> Version: 2.4.35 >>> OS: Debian Wheezy >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (131.156.2.26) >>> >>> >>> slapd sporadically crashes in slapd_free_controls when syncrepl enabled > and plugins are in use. The crash is caused by an invalid free in the > slapi overlay; it only occurs on the provider in a syncrepl setup. > This is the backtrace: >> >> Didn't you already report this in ITS#7636? Why are you opening an new > ITS? >> >> --Quanah > > This is a different crash with a different cause and completely different > backtrace. As far as I can tell there were two separate crashes related > to syncrepl with slapi plugins enabled. The one I reported in ITS#7636 > was constant and easily reproducible, therefore it somewhat masked the > crash I have reported in this bug report. > > Should the two reports be merged even though the causes and backtraces are > different? Nope, I just wanted to confirm it wasn't a duplicate. Thanks! --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by kb9vqf＠pearsoncomputing.net 18 Jul '13

18 Jul '13

> --On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: > >> Full_Name: Timothy Pearson >> Version: 2.4.35 >> OS: Debian Wheezy >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.156.2.26) >> >> >> slapd sporadically crashes in slapd_free_controls when syncrepl enabled and plugins are in use. The crash is caused by an invalid free in the slapi overlay; it only occurs on the provider in a syncrepl setup. This is the backtrace: > > Didn't you already report this in ITS#7636? Why are you opening an new ITS? > > --Quanah This is a different crash with a different cause and completely different backtrace. As far as I can tell there were two separate crashes related to syncrepl with slapi plugins enabled. The one I reported in ITS#7636 was constant and easily reproducible, therefore it somewhat masked the crash I have reported in this bug report. Should the two reports be merged even though the causes and backtraces are different?

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by quanah＠zimbra.com 18 Jul '13

18 Jul '13

--On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: > Full_Name: Timothy Pearson > Version: 2.4.35 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.156.2.26) > > > slapd sporadically crashes in slapd_free_controls when syncrepl enabled > and plugins are in use. The crash is caused by an invalid free in the > slapi overlay; it only occurs on the provider in a syncrepl setup. This > is the backtrace: Didn't you already report this in ITS#7636? Why are you opening an new ITS? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by kb9vqf＠pearsoncomputing.net 18 Jul '13

18 Jul '13

Full_Name: Timothy Pearson Version: 2.4.35 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.156.2.26) slapd sporadically crashes in slapd_free_controls when syncrepl enabled and plugins are in use. The crash is caused by an invalid free in the slapi overlay; it only occurs on the provider in a syncrepl setup. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe1536700 (LWP 24523)] *__GI___libc_free (mem=0x18) at malloc.c:3709 3709 malloc.c: No such file or directory. (gdb) (gdb) bt #0 *__GI___libc_free (mem=0x18) at malloc.c:3709 #1 0x00007ffff7974d01 in ber_memfree_x (p=0x18, ctx=0x0) at ../../../../libraries/liblber/memory.c:152 #2 0x00005555555c3003 in slap_free_ctrls (op=0x555555ef0c60, ctrls=0x555555ef2570) at ../../../../servers/slapd/controls.c:569 #3 0x00005555555a41e5 in slap_send_search_entry (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/result.c:1476 #4 0x00007ffff1e4c465 in hdb_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at search.c:1014 #5 0x00005555555ff1c6 in overlay_op_walk (op=0x555555ef0c60, rs=0x7fffe1535a40, which=op_search, oi=0x5555559e5e70, on=0x0) at ../../../../servers/slapd/backover.c:671 #6 0x00007ffff63bfe5a in slapi_op_func (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../../servers/slapd/slapi/slapi_overlay.c:650 #7 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555ef0c60, rs=0x7fffe1535a40, which=op_search, oi=0x5555559e5e70, on=0x5555559e6a60) at ../../../../servers/slapd/backover.c:661 #8 0x00005555555ff31b in over_op_func (op=0x555555ef0c60, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #9 0x0000555555594641 in fe_op_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/search.c:402 #10 0x0000555555593f06 in do_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/search.c:247 #11 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe1535bd0, arg_v=arg_v@entry=0x555555ef0c60) at ../../../../servers/slapd/connection.c:1150 #12 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe1535bd0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #13 0x00007ffff7b8dfbb in ldap_int_thread_pool_wrapper (xpool=0x55555590a2e0) at ../../../../libraries/libldap_r/tpool.c:688 #14 0x00007ffff5d79b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #15 0x00007ffff5ac3a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #16 0x0000000000000000 in ?? () (gdb) This patch fixes the problem: --- servers/slapd/slapi/slapi_overlay.c +++ servers/slapd/slapi/slapi_overlay.c @@ -454,11 +454,11 @@ n_slapi_ctrls = slapi_int_count_controls( slapi_ctrls ); n_rs_ctrls = slapi_int_count_controls( rs->sr_ctrls ); - slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); - if ( n_slapi_ctrls == 0 ) return LDAP_SUCCESS; /* no SLAPI controls */ + slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); + ctrls = (LDAPControl **) op->o_tmpalloc( ( n_slapi_ctrls + n_rs_ctrls + 1 ) * sizeof(LDAPControl *), op->o_tmpmemctx );

1 0

Re: (ITS#7639) test062-config-delete intermittently succeeds
by hyc＠symas.com 14 Jul '13

14 Jul '13

rsbx(a)acm.org wrote: > Full_Name: Raymond S Brand > Version: 60720f5d9cdc19092d0aad6b0a94e196e5525d1c > OS: Debian Wheezy amd64 > URL: > Submission from: (NULL) (50.88.155.14) > The following is the output from valgrind for the above run. Valgrind was used > specifically to aid in creating this bug report; it is not part of my normal > testing of this software. The output is puzzling. It shows syncprov_db_close accessing a persistent search structure that was already freed in syncprov_op_abandon. The puzzling part is that syncprov_db_close can only find ops by following the si->si_op list, and syncprov_op_abandon always removes ops from the si_op list before it frees anything. Will have to look into this later, but now you can see why this feature is not part of the public 2.4 releases. Nor will it be, it's a 2.5 feature. > ==2454== Memcheck, a memory error detector > ==2454== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==2454== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==2454== Command: /home/internet/Projects/OpenLDAP/openldap/BUILD/t2/tests/../servers/slapd/slapd > -s0 -F ./slapd.d -h ldap://localhost:9011/ -d 0x4105 > ==2454== Parent PID: 2442 > ==2454== > ==2454== Thread 4: > ==2454== Invalid read of size 8 > ==2454== at 0x45006E: send_ldap_response (result.c:704) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450072: send_ldap_response (result.c:704) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x45007F: send_ldap_response (result.c:705) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450083: send_ldap_response (result.c:705) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x44FD85: send_ldap_response (result.c:716) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cdb8 is 312 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450B28: slap_send_ldap_result (result.c:845) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc88 is 8 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450CD1: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FA4CBA: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FD4480: _IO_default_xsputn (genops.c:480) > ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FD4492: _IO_default_xsputn (genops.c:479) > ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== Address 0xa23ce3a is 442 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x5572BC: syncprov_db_close (syncprov.c:3179) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== by 0x440C1D: connection_read_thread (connection.c:1291) > ==2454== Address 0xa23cbc0 is 0 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x555F78: syncprov_drop_psearch (syncprov.c:1099) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc00 is 64 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F86: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cbe0 is 32 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F8A: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F8D: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23ce00 is 384 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0x168 is not stack'd, malloc'd or (recently) free'd > ==2454== > ==2454== > ==2454== Process terminating with default action of signal 11 (SIGSEGV) > ==2454== Access not within mapped region at address 0x168 > ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== If you believe this happened as a result of a stack > ==2454== overflow in your program's main thread (unlikely but > ==2454== possible), you can try to increase the size of the > ==2454== main thread stack using the --main-stacksize= flag. > ==2454== The main thread stack size used in this run was 8388608. > ==2454== > ==2454== HEAP SUMMARY: > ==2454== in use at exit: 6,002,487 bytes in 13,317 blocks > ==2454== total heap usage: 22,504 allocs, 9,187 frees, 8,818,779 bytes > allocated > ==2454== > ==2454== LEAK SUMMARY: > ==2454== definitely lost: 0 bytes in 0 blocks > ==2454== indirectly lost: 0 bytes in 0 blocks > ==2454== possibly lost: 1,152 bytes in 4 blocks > ==2454== still reachable: 6,001,335 bytes in 13,313 blocks > ==2454== suppressed: 0 bytes in 0 blocks > ==2454== Rerun with --leak-check=full to see details of leaked memory > ==2454== > ==2454== For counts of detected and suppressed errors, rerun with: -v > ==2454== ERROR SUMMARY: 42 errors from 16 contexts (suppressed: 31 from 9) > ~ > ~ > > -- -- 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#7640) LDAP_OPT_CONNECT_ASYNC
by quanah＠zimbra.com 12 Jul '13

12 Jul '13

--On Friday, July 12, 2013 3:13 PM +0000 jeremy.hustache(a)netasq.com wrote: > Full_Name: jeremy hustache > Version: 2.4.31 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.218.228.130) The ITS system is for reporting bugs, not asking questions. Please direct your questions to openldap-technical(a)openldap.org. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7640) LDAP_OPT_CONNECT_ASYNC
by jeremy.hustache＠netasq.com 12 Jul '13

12 Jul '13

Full_Name: jeremy hustache Version: 2.4.31 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.218.228.130) I want to use ldap_simple_bind completely asynchronously (for the connect level and bind request). My code is the following: ldap_set_option(ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON); rc = ldap_simple_bind(ld, user, password); I set also options LDAP_OPT_NETWORK_TIMEOUT before calling ldap_simple_bind. rc is still equal to -1 and ldap_err2string(rc) returns "Can't contact LDAP server" If I call ldap_simple_bind without calling previously ldap_set_option(ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON), rc is successful. So can I use ldap_opt_connect_async in this case ?

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 10 Jul '13

10 Jul '13

> Somewhat of a workaround - slapi should not be doing anything here unless > the > filter was actually changed. > > syncprov is using (objectclass=*) which frankly no plugin should be > rewriting, > so this will cover it for the most part. Aside from that it looks like > this > area of the slapi interaction needs some redesign. Ignore my earlier noise please--an old (unpatched) libslapi library was present on the system from earlier debugging attempts, this was what caused the recent crash. Your patch seems to work! Thank you for your quick response; we now have a shot at going forward with the OpenLDAP deployment. Tim

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 10 Jul '13

10 Jul '13

> Somewhat of a workaround - slapi should not be doing anything here unless the > filter was actually changed. > > syncprov is using (objectclass=*) which frankly no plugin should be rewriting, > so this will cover it for the most part. Aside from that it looks like this > area of the slapi interaction needs some redesign. > > -- Unfortunately the workaround didn't help: Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe2ca2700 (LWP 29843)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe2c9fff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe2c9fff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe2c9ff80, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe2c9fff0, rs=0x7fffe2c9ff80) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe2c9fff0, rs=0x7fffe2c9ff80, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe2c9fff0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4a45b in syncprov_findbase (op=op@entry=0x555555eeff60, fc=fc@entry=0x7fffe2ca0290) at syncprov.c:465 #11 0x00007ffff1c4cd87 in syncprov_op_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at syncprov.c:2461 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60, rs=rs@entry=0x7fffe2ca1a50, which=which@entry=op_search, oi=0x5555559e5680, on=0x5555559bfbe0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe2ca1a50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60, rs=0x7fffe2ca1a50, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555eeff60, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe2ca1ba0, arg_v=arg_v@entry=0x555555eeff60) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe2ca1ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () (gdb) Valgrind doesn't turn up anything strange before the crash, so I guess it comes down to design error in a relatively untested code path. Tim

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

> kb9vqf(a)pearsoncomputing.net wrote: >> Unfortunately the previous patch only fixes some of the most obvious (immediate) crashes. There are other places in the code (e.g. >> syncprov.c >> line 647) which pass non-malloc()ed variables to be_search() and thereby crash slapd. >> >> Has syncrepl even been tested with plugins before? We really wanted to use OpenLDAP for our directory server, however if replication cannot be used with plugins then we may need to go with a Microsoft solution instead. >> >> Any hints? > > Seems like the problem should be fixed in the slapi support code. And in general, the slapi code receives very little attention since slapd overlays > are the native plugin mechanism. Patching syncprov.c is definitely the wrong > way to go though. OK, thanks for the info. I don't know much acout the internals of OpenLDAP, but I can still see where non-malloc()ed memory is being passed (eventually) to a free()-type function. ;-) > What are the plugins you're trying to use? Are you sure there isn't already a > slapd overlay that provides the feature? We use a custom plugin to keep Kerberos ACLs in sync with group memberships. The plugin only monitors for certain changes to the directory, it does not modify the directory in any way.

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 09 Jul '13

09 Jul '13

This is a multi-part message in MIME format. --------------090107030705000509000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit kb9vqf(a)pearsoncomputing.net wrote: > Unfortunately the previous patch only fixes some of the most obvious > (immediate) crashes. There are other places in the code (e.g. syncprov.c > line 647) which pass non-malloc()ed variables to be_search() and thereby > crash slapd. > > Has syncrepl even been tested with plugins before? We really wanted to > use OpenLDAP for our directory server, however if replication cannot be > used with plugins then we may need to go with a Microsoft solution > instead. > > Any hints? Somewhat of a workaround - slapi should not be doing anything here unless the filter was actually changed. syncprov is using (objectclass=*) which frankly no plugin should be rewriting, so this will cover it for the most part. Aside from that it looks like this area of the slapi interaction needs some 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/ --------------090107030705000509000908 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/slapi/slapi_overlay.c b/servers/slapd/slapi/slapi_overlay.c index 0db4ce2..ad23153 100644 --- a/servers/slapd/slapi/slapi_overlay.c +++ b/servers/slapd/slapi/slapi_overlay.c @@ -296,6 +296,7 @@ static int slapi_op_search_callback( Operation *op, SlapReply *rs, int prc ) { Slapi_PBlock *pb = SLAPI_OPERATION_PBLOCK( op ); + Filter *f = op->ors_filter; /* check preoperation result code */ if ( prc < 0 ) { @@ -310,8 +311,10 @@ slapi_op_search_callback( Operation *op, SlapReply *rs, int prc ) * The plugin can set the SLAPI_SEARCH_FILTER. * SLAPI_SEARCH_STRFILER is not normative. */ - op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); - filter2bv_x( op, op->ors_filter, &op->ors_filterstr ); + if (f != op->ors_filter) { + op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); + filter2bv_x( op, op->ors_filter, &op->ors_filterstr ); + } } return LDAP_SUCCESS; --------------090107030705000509000908--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 09 Jul '13

09 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: > Unfortunately the previous patch only fixes some of the most obvious > (immediate) crashes. There are other places in the code (e.g. syncprov.c > line 647) which pass non-malloc()ed variables to be_search() and thereby > crash slapd. > > Has syncrepl even been tested with plugins before? We really wanted to > use OpenLDAP for our directory server, however if replication cannot be > used with plugins then we may need to go with a Microsoft solution > instead. > > Any hints? Seems like the problem should be fixed in the slapi support code. And in general, the slapi code receives very little attention since slapd overlays are the native plugin mechanism. Patching syncprov.c is definitely the wrong way to go though. What are the plugins you're trying to use? Are you sure there isn't already a slapd overlay that provides the feature? -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

Unfortunately the previous patch only fixes some of the most obvious (immediate) crashes. There are other places in the code (e.g. syncprov.c line 647) which pass non-malloc()ed variables to be_search() and thereby crash slapd. Has syncrepl even been tested with plugins before? We really wanted to use OpenLDAP for our directory server, however if replication cannot be used with plugins then we may need to go with a Microsoft solution instead. Any hints?

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

------=_20130709125114_66017 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I have traced the fault into the syncrepl overlay, specifically it passes a static global variable to be_search(). If a plugin is configured, slapi_op_search_callback() is called, which then attempts to free the static global search variable passed to be_search(), causing a crash. The attached patch fixes the problem on my test system. ------=_20130709125114_66017 Content-Type: text/x-patch; name="openldap_syncprov_plugin_crash_fix.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="openldap_syncprov_plugin_crash_fix.diff" --- servers/slapd/overlays/syncprov.c +++ servers/slapd/overlays/syncprov.c @@ -460,7 +460,13 @@ fop.ors_attrs = slap_anlist_no_attrs; fop.ors_attrsonly = 1; fop.ors_filter = &generic_filter; - fop.ors_filterstr = generic_filterstr; + + // If any plugins are enabled, slapi_overlay will attempt to free the provided filter string in slapi_op_search_callback, causing a crash + // Therefore, allocate a copy of generic_filterstr for use by be_search() + struct berval filterstr; + filterstr.bv_len = generic_filterstr.bv_len; + filterstr.bv_val = op->o_tmpalloc(generic_filterstr.bv_len + 1, op->o_tmpmemctx); + memcpy(filterstr.bv_val, generic_filterstr.bv_val, generic_filterstr.bv_len + 1); rc = fop.o_bd->be_search( &fop, &frs ); } else { ------=_20130709125114_66017--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

Here is the backtrace with the above dummy plugin on the latest OpenLDAP (2.4.35): Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe34a3700 (LWP 15269)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe34a0ff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe34a0ff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe34a0f80, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe34a0ff0, rs=0x7fffe34a0f80) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe34a0ff0, rs=0x7fffe34a0f80, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe34a0ff0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4a45b in syncprov_findbase (op=op@entry=0x555555f093c0, fc=fc@entry=0x7fffe34a1290) at syncprov.c:465 #11 0x00007ffff1c4cd87 in syncprov_op_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at syncprov.c:2461 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555f093c0, rs=rs@entry=0x7fffe34a2a50, which=which@entry=op_search, oi=0x5555559e5680, on=0x5555559bfbe0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe34a2a50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555f093c0, rs=0x7fffe34a2a50, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555f093c0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe34a2ba0, arg_v=arg_v@entry=0x555555f093c0) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe34a2ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () (gdb)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs