openldap-bugs July 2013

openldap-bugs@openldap.org

23 participants
85 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2013