openldap-bugs May 2014

openldap-bugs@openldap.org

26 participants
75 discussions

Re: (ITS#7862) slapd crash on modifications after host hard reset (in mdb)
by hyc＠symas.com 28 May '14

28 May '14

Vadim Prozorov wrote: > Excuse me, where I can read about mapasync limitations on Linux? > http://symas.com/mdb/doc/group__mdb__env.html#gab034ed0d8e5938090aef5ee0997… > contains no such info. Seems to me I've missed some important info about > configuration. MAPASYNC uses msync(... MS_ASYNC). Google for this with Linux will give you results like so: http://www.spinics.net/lists/linux-mm/msg71244.html > > And in addition - is there way to check DB health status without running slapd? What health status? The mdb_stat command will return info about the DB. > > > 2014-05-28 15:02 GMT+04:00 Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>>: > > Vadim Prozorov wrote: > > Did you have dbnosync configured on this backend? Looks like > garbage data > got written to the freeDB. > > > No, DB config section is: > # define MDB parameters > backendmdb > databasemdb > maxsize20000000000 > envflagswritemap mapasync > # end define > > > Unfortunately, in Linux mapasync is a no-op. It seems then that your DB is > quite corrupted. > > > -- > -- 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#7862) slapd crash on modifications after host hard reset (in mdb)
by vadius＠vadius.ru 28 May '14

28 May '14

--f46d044288025e7ce404fa740f82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excuse me, where I can read about mapasync limitations on Linux? http://symas.com/mdb/doc/group__mdb__env.html#gab034ed0d8e5938090aef5ee0997= f7e94contains no such info. Seems to me I've missed some important info about configuration. And in addition - is there way to check DB health status without running slapd? 2014-05-28 15:02 GMT+04:00 Howard Chu <hyc(a)symas.com>: > Vadim Prozorov wrote: > >> Did you have dbnosync configured on this backend? Looks like garbage >> data >> got written to the freeDB. >> >> >> No, DB config section is: >> # define MDB parameters >> backendmdb >> databasemdb >> maxsize20000000000 >> envflagswritemap mapasync >> # end define >> > > Unfortunately, in Linux mapasync is a no-op. It seems then that your DB i= s > quite corrupted. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=92=D0=B0=D0=B4=D0=B8=D0=BC =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE= =D0=B2. --f46d044288025e7ce404fa740f82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Excuse me, where I can read about mapasync limitations on = Linux?<div><a href=3D"http://symas.com/mdb/doc/group__mdb__env.html#gab034e= d0d8e5938090aef5ee0997f7e94">http://symas.com/mdb/doc/group__mdb__env.html#= gab034ed0d8e5938090aef5ee0997f7e94</a> contains no such info. Seems to me I= 've missed some important info about configuration.<br> </div><div><br></div><div>And in addition - is there way to check DB health= status without running slapd?</div></div><div class=3D"gmail_extra"><br><b= r><div class=3D"gmail_quote">2014-05-28 15:02 GMT+04:00 Howard Chu <span di= r=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.= com</a>></span>:<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"">Vadim Prozorov wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 Did you have dbnosync configured on this backend? Looks like = garbage data<br> =C2=A0 =C2=A0 got written to the freeDB.<br> <br> <br> No, DB config section is:<br> # define MDB parameters<br> backendmdb<br> databasemdb<br> maxsize20000000000<br> envflagswritemap mapasync<br> # end define<br> </blockquote> <br></div> Unfortunately, in Linux mapasync is a no-op. It seems then that your DB is = quite corrupted.<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= <div>=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC,<br>=D0= =92=D0=B0=D0=B4=D0=B8=D0=BC =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0= =B2.</div><div><br></div> </div> --f46d044288025e7ce404fa740f82--

1 0

Re: (ITS#7862) slapd crash on modifications after host hard reset (in mdb)
by hyc＠symas.com 28 May '14

28 May '14

Vadim Prozorov wrote: > Did you have dbnosync configured on this backend? Looks like garbage data > got written to the freeDB. > > > No, DB config section is: > # define MDB parameters > backendmdb > databasemdb > maxsize20000000000 > envflagswritemap mapasync > # end define Unfortunately, in Linux mapasync is a no-op. It seems then that your DB is quite corrupted. -- -- 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

Fwd: (ITS#7862) slapd crash on modifications after host hard reset (in mdb)
by vadius＠vadius.ru 28 May '14

28 May '14

--047d7b5d285813733e04fa73805f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014-05-28 13:47 GMT+04:00 Howard Chu <hyc(a)symas.com>: vadius(a)vadius.ru wrote: > >> Full_Name: Vadim Prozorov >> Version: 2.4.38 >> OS: RHEL 6.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (91.210.4.1) >> >> >> Hello, >> >> I'm using slapd (2.4.38 release) built from sources on RHEL 6.3 64bit. >> Build params: >> LD_LIBRARY_PATH=3D"/usr/lib:/usr/local/lib:/opt/local/BerkeleyDB.5.3/lib= " >> LDFLAGS=3D"-L/usr/local/lib -L/opt/local/BerkeleyDB.5.3/lib" >> CPPFLAGS=3D"-I/usr/local/include -I/opt/local/BerkeleyDB.5.3/include" >> ./configure >> --prefix=3D/opt/local/OpenLDAP --enable-dynacl --enable-ldap >> =E2=80=94enable-overlays >> --disable-static --enable-dynamic >> >> slapd works in master-master sync mode on host with big amount of RAM >> (whole DB >> can fit into RAM). >> One time host was hardly restarted. After restart slapd has started, but >> crash >> on any modification (at least, from ext application; may be form replica= , >> haven't check yet). There is always the same crash stack: >> > > Did you have dbnosync configured on this backend? Looks like garbage data > got written to the freeDB. > No, DB config section is: # define MDB parameters backend mdb database mdb maxsize 20000000000 envflags writemap mapasync # end define > > (gdb) bt >> #0 mdb_xcursor_init1 (mc=3D0x7f3e1d6bbd40, node=3D0x7f3f99f46f82) at >> ./../../../libraries/liblmdb/mdb.c:6585 >> #1 0x000000000049f8eb in mdb_cursor_set (mc=3D0x7f3e1d6bbd40, >> key=3D0x7f3e1d6bbef0, >> data=3D0x0, op=3DMDB_SET_RANGE, exactp=3D<value optimized out>) at >> ./../../../libraries/liblmdb/mdb.c:5329 >> #2 0x00000000004a019f in mdb_cursor_get (mc=3D0x7f3e1d6bbd40, >> key=3D0x7f3e1d6bbef0, >> data=3D0x0, op=3D<value optimized out>) at ./../../../libraries/liblmdb/ >> mdb.c:5529 >> #3 0x000000000049e0ed in mdb_page_alloc (mc=3D<value optimized out>, nu= m=3D1, >> mp=3D0x7f3e1d6bbf68) at ./../../../libraries/liblmdb/mdb.c:1727 >> #4 0x000000000049e469 in mdb_page_touch (mc=3D0x7f3e1d6bc1d0) at >> ./../../../libraries/liblmdb/mdb.c:1911 >> #5 0x000000000049eb3a in mdb_page_search (mc=3D0x7f3e1d6bc1d0, key=3D0x= 0, >> flags=3D5) >> at ./../../../libraries/liblmdb/mdb.c:4830 >> #6 0x00000000004a7404 in mdb_freelist_save (txn=3D0x7f3e10115130) at >> ./../../../libraries/liblmdb/mdb.c:2522 >> #7 mdb_txn_commit (txn=3D0x7f3e10115130) at >> ./../../../libraries/liblmdb/mdb.c:2972 >> #8 0x00000000004a9e4e in mdb_modify (op=3D0x7f3e100028f0, >> rs=3D0x7f3e1d6bd910) at >> modify.c:664 >> #9 0x000000000043b4cb in fe_op_modify (op=3D0x7f3e100028f0, >> rs=3D0x7f3e1d6bd910) at >> modify.c:303 >> #10 0x000000000043bdf6 in do_modify (op=3D0x7f3e100028f0, >> rs=3D0x7f3e1d6bd910) at >> modify.c:177 >> #11 0x0000000000423c99 in connection_operation (ctx=3D0x7f3e1d6bda70, >> arg_v=3D0x7f3e100028f0) at connection.c:1155 >> #12 0x0000000000424475 in connection_read_thread (ctx=3D0x7f3e1d6bda70, >> argv=3D<value optimized out>) at connection.c:1291 >> #13 0x00007f3f9b6f04e8 in ldap_int_thread_pool_wrapper (xpool=3D0x16f36d= 0) >> at >> tpool.c:688 >> #14 0x0000003b6f2079d1 in start_thread () from /lib64/libpthread.so.0 >> #15 0x0000003b6eee8b6d in clone () from /lib64/libc.so.6 >> >> Crash can be reproduced by using data.mdb file on any host with the same >> slapd >> binaries. >> Also note contextCSN of DB became 'old' - it was actual on May 22 for bo= th >> instances, when reset occured, but after start context CSN shows May 21 >> and 20. >> >> Also mdb_stat utility crashes on attempt to show FreeDB data: >> $ mdb_stat -f ./data >> Freelist Status >> Tree depth: 3 >> Branch pages: 7 >> Leaf pages: 817 >> Overflow pages: 0 >> Entries: 16995 >> Segmentation fault (core dumped) >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- WBR, Vadim Prozorov --047d7b5d285813733e04fa73805f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr"><div><= div class=3D"h5"><div class=3D"gmail_quote"><div dir=3D"ltr"><div class=3D"= gmail_extra"><div class=3D"gmail_quote">2014-05-28 13:47 GMT+04:00 Howard C= hu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank"= >hyc(a)symas.com</a>></span>:<div> <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol= id;padding-left:1ex"> <a href=3D"mailto:vadius@vadius.ru" target=3D"_blank">vadius(a)vadius.ru</a> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Full_Name: Vadim Prozorov<br> Version: 2.4.38<br> OS: RHEL 6.3<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (91.210.4.1)<br> <br> <br> Hello,<br> <br> I'm using slapd (2.4.38 release) built from sources on RHEL 6.3 64bit.<= br> Build params:<br> LD_LIBRARY_PATH=3D"/usr/lib:/<u></u>usr/local/lib:/opt/local/<u></u>Be= rkeleyDB.5.3/lib"<br> LDFLAGS=3D"-L/usr/local/lib -L/opt/local/BerkeleyDB.5.3/<u></u>lib&quo= t;<br> CPPFLAGS=3D"-I/usr/local/include -I/opt/local/BerkeleyDB.5.3/<u></u>in= clude" ./configure<br> --prefix=3D/opt/local/OpenLDAP --enable-dynacl --enable-ldap =E2=80=94enabl= e-overlays<br> --disable-static --enable-dynamic<br> <br> slapd works in master-master sync mode on host with big amount of RAM (whol= e DB<br> can fit into RAM).<br> One time host was hardly restarted. After restart slapd has started, but cr= ash<br> on any modification (at least, from ext application; may be form replica,<b= r> haven't check yet). There is always the same crash stack:<br> </blockquote> <br> Did you have dbnosync configured on this backend? Looks like garbage data g= ot written to the freeDB.<br></blockquote><div><br></div></div><div>No, DB = config section is:</div><div># define MDB parameters =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div> <div>backend<span style=3D"white-space:pre-wrap"> </span>mdb</div><div>dat= abase<span style=3D"white-space:pre-wrap"> </span>mdb</div><div>max= size<span style=3D"white-space:pre-wrap"> 20</span>000000000</div> <div>envflags<span style=3D"white-space:pre-wrap"> </span>writemap mapasync= </div><div># end define</div><div><div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> (gdb) bt<br> #0 =C2=A0mdb_xcursor_init1 (mc=3D0x7f3e1d6bbd40, node=3D0x7f3f99f46f82) at<= br> ./../../../libraries/liblmdb/<u></u>mdb.c:6585<br> #1 =C2=A00x000000000049f8eb in mdb_cursor_set (mc=3D0x7f3e1d6bbd40, key=3D0= x7f3e1d6bbef0,<br> data=3D0x0, op=3DMDB_SET_RANGE, exactp=3D<value optimized out>) at<br= > ./../../../libraries/liblmdb/<u></u>mdb.c:5329<br> #2 =C2=A00x00000000004a019f in mdb_cursor_get (mc=3D0x7f3e1d6bbd40, key=3D0= x7f3e1d6bbef0,<br> data=3D0x0, op=3D<value optimized out>) at ./../../../libraries/liblm= db/<u></u>mdb.c:5529<br> #3 =C2=A00x000000000049e0ed in mdb_page_alloc (mc=3D<value optimized out= >, num=3D1,<br> mp=3D0x7f3e1d6bbf68) at ./../../../libraries/liblmdb/<u></u>mdb.c:1727<br> #4 =C2=A00x000000000049e469 in mdb_page_touch (mc=3D0x7f3e1d6bc1d0) at<br> ./../../../libraries/liblmdb/<u></u>mdb.c:1911<br> #5 =C2=A00x000000000049eb3a in mdb_page_search (mc=3D0x7f3e1d6bc1d0, key=3D= 0x0, flags=3D5)<br> at ./../../../libraries/liblmdb/<u></u>mdb.c:4830<br> #6 =C2=A00x00000000004a7404 in mdb_freelist_save (txn=3D0x7f3e10115130) at<= br> ./../../../libraries/liblmdb/<u></u>mdb.c:2522<br> #7 =C2=A0mdb_txn_commit (txn=3D0x7f3e10115130) at<br> ./../../../libraries/liblmdb/<u></u>mdb.c:2972<br> #8 =C2=A00x00000000004a9e4e in mdb_modify (op=3D0x7f3e100028f0, rs=3D0x7f3e= 1d6bd910) at<br> modify.c:664<br> #9 =C2=A00x000000000043b4cb in fe_op_modify (op=3D0x7f3e100028f0, rs=3D0x7f= 3e1d6bd910) at<br> modify.c:303<br> #10 0x000000000043bdf6 in do_modify (op=3D0x7f3e100028f0, rs=3D0x7f3e1d6bd9= 10) at<br> modify.c:177<br> #11 0x0000000000423c99 in connection_operation (ctx=3D0x7f3e1d6bda70,<br> arg_v=3D0x7f3e100028f0) at connection.c:1155<br> #12 0x0000000000424475 in connection_read_thread (ctx=3D0x7f3e1d6bda70,<br> argv=3D<value optimized out>) at connection.c:1291<br> #13 0x00007f3f9b6f04e8 in ldap_int_thread_pool_wrapper (xpool=3D0x16f36d0) = at<br> tpool.c:688<br> #14 0x0000003b6f2079d1 in start_thread () from /lib64/libpthread.so.0<br> #15 0x0000003b6eee8b6d in clone () from /lib64/libc.so.6<br> <br> Crash can be reproduced by using data.mdb file on any host with the same sl= apd<br> binaries.<br> Also note contextCSN of DB became 'old' - it was actual on May 22 f= or both<br> instances, when reset occured, but after start context CSN shows May 21 and= 20.<br> <br> Also mdb_stat utility crashes on attempt to show FreeDB data:<br> $ mdb_stat -f ./data<br> Freelist Status<br> =C2=A0 =C2=A0Tree depth: 3<br> =C2=A0 =C2=A0Branch pages: 7<br> =C2=A0 =C2=A0Leaf pages: 817<br> =C2=A0 =C2=A0Overflow pages: 0<br> =C2=A0 =C2=A0Entries: 16995<br> Segmentation fault (core dumped)<br> <br> <br><span><font color=3D"#888888"> </font></span></blockquote><span><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div></div></div><span><font color=3D"#888888">= <br></font></span></div></div></div>--</div></div><div>WBR,</div><div>Vadim= Prozorov</div></div></div> </div> --047d7b5d285813733e04fa73805f--

1 0

Re: (ITS#7862) slapd crash on modifications after host hard reset (in mdb)
by hyc＠symas.com 28 May '14

28 May '14

vadius(a)vadius.ru wrote: > Full_Name: Vadim Prozorov > Version: 2.4.38 > OS: RHEL 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.210.4.1) > > > Hello, > > I'm using slapd (2.4.38 release) built from sources on RHEL 6.3 64bit. > Build params: > LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/opt/local/BerkeleyDB.5.3/lib" > LDFLAGS="-L/usr/local/lib -L/opt/local/BerkeleyDB.5.3/lib" > CPPFLAGS="-I/usr/local/include -I/opt/local/BerkeleyDB.5.3/include" ./configure > --prefix=/opt/local/OpenLDAP --enable-dynacl --enable-ldap enable-overlays > --disable-static --enable-dynamic > > slapd works in master-master sync mode on host with big amount of RAM (whole DB > can fit into RAM). > One time host was hardly restarted. After restart slapd has started, but crash > on any modification (at least, from ext application; may be form replica, > haven't check yet). There is always the same crash stack: Did you have dbnosync configured on this backend? Looks like garbage data got written to the freeDB. > (gdb) bt > #0 mdb_xcursor_init1 (mc=0x7f3e1d6bbd40, node=0x7f3f99f46f82) at > ./../../../libraries/liblmdb/mdb.c:6585 > #1 0x000000000049f8eb in mdb_cursor_set (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, > data=0x0, op=MDB_SET_RANGE, exactp=<value optimized out>) at > ./../../../libraries/liblmdb/mdb.c:5329 > #2 0x00000000004a019f in mdb_cursor_get (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, > data=0x0, op=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:5529 > #3 0x000000000049e0ed in mdb_page_alloc (mc=<value optimized out>, num=1, > mp=0x7f3e1d6bbf68) at ./../../../libraries/liblmdb/mdb.c:1727 > #4 0x000000000049e469 in mdb_page_touch (mc=0x7f3e1d6bc1d0) at > ./../../../libraries/liblmdb/mdb.c:1911 > #5 0x000000000049eb3a in mdb_page_search (mc=0x7f3e1d6bc1d0, key=0x0, flags=5) > at ./../../../libraries/liblmdb/mdb.c:4830 > #6 0x00000000004a7404 in mdb_freelist_save (txn=0x7f3e10115130) at > ./../../../libraries/liblmdb/mdb.c:2522 > #7 mdb_txn_commit (txn=0x7f3e10115130) at > ./../../../libraries/liblmdb/mdb.c:2972 > #8 0x00000000004a9e4e in mdb_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at > modify.c:664 > #9 0x000000000043b4cb in fe_op_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at > modify.c:303 > #10 0x000000000043bdf6 in do_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at > modify.c:177 > #11 0x0000000000423c99 in connection_operation (ctx=0x7f3e1d6bda70, > arg_v=0x7f3e100028f0) at connection.c:1155 > #12 0x0000000000424475 in connection_read_thread (ctx=0x7f3e1d6bda70, > argv=<value optimized out>) at connection.c:1291 > #13 0x00007f3f9b6f04e8 in ldap_int_thread_pool_wrapper (xpool=0x16f36d0) at > tpool.c:688 > #14 0x0000003b6f2079d1 in start_thread () from /lib64/libpthread.so.0 > #15 0x0000003b6eee8b6d in clone () from /lib64/libc.so.6 > > Crash can be reproduced by using data.mdb file on any host with the same slapd > binaries. > Also note contextCSN of DB became 'old' - it was actual on May 22 for both > instances, when reset occured, but after start context CSN shows May 21 and 20. > > Also mdb_stat utility crashes on attempt to show FreeDB data: > $ mdb_stat -f ./data > Freelist Status > Tree depth: 3 > Branch pages: 7 > Leaf pages: 817 > Overflow pages: 0 > Entries: 16995 > Segmentation fault (core dumped) > > -- -- 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#7862) slapd crash on modifications after host hard reset (in mdb)
by vadius＠vadius.ru 28 May '14

28 May '14

Full_Name: Vadim Prozorov Version: 2.4.38 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) Hello, I'm using slapd (2.4.38 release) built from sources on RHEL 6.3 64bit. Build params: LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/opt/local/BerkeleyDB.5.3/lib" LDFLAGS="-L/usr/local/lib -L/opt/local/BerkeleyDB.5.3/lib" CPPFLAGS="-I/usr/local/include -I/opt/local/BerkeleyDB.5.3/include" ./configure --prefix=/opt/local/OpenLDAP --enable-dynacl --enable-ldap enable-overlays --disable-static --enable-dynamic slapd works in master-master sync mode on host with big amount of RAM (whole DB can fit into RAM). One time host was hardly restarted. After restart slapd has started, but crash on any modification (at least, from ext application; may be form replica, haven't check yet). There is always the same crash stack: (gdb) bt #0 mdb_xcursor_init1 (mc=0x7f3e1d6bbd40, node=0x7f3f99f46f82) at ./../../../libraries/liblmdb/mdb.c:6585 #1 0x000000000049f8eb in mdb_cursor_set (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, data=0x0, op=MDB_SET_RANGE, exactp=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:5329 #2 0x00000000004a019f in mdb_cursor_get (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, data=0x0, op=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:5529 #3 0x000000000049e0ed in mdb_page_alloc (mc=<value optimized out>, num=1, mp=0x7f3e1d6bbf68) at ./../../../libraries/liblmdb/mdb.c:1727 #4 0x000000000049e469 in mdb_page_touch (mc=0x7f3e1d6bc1d0) at ./../../../libraries/liblmdb/mdb.c:1911 #5 0x000000000049eb3a in mdb_page_search (mc=0x7f3e1d6bc1d0, key=0x0, flags=5) at ./../../../libraries/liblmdb/mdb.c:4830 #6 0x00000000004a7404 in mdb_freelist_save (txn=0x7f3e10115130) at ./../../../libraries/liblmdb/mdb.c:2522 #7 mdb_txn_commit (txn=0x7f3e10115130) at ./../../../libraries/liblmdb/mdb.c:2972 #8 0x00000000004a9e4e in mdb_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:664 #9 0x000000000043b4cb in fe_op_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:303 #10 0x000000000043bdf6 in do_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:177 #11 0x0000000000423c99 in connection_operation (ctx=0x7f3e1d6bda70, arg_v=0x7f3e100028f0) at connection.c:1155 #12 0x0000000000424475 in connection_read_thread (ctx=0x7f3e1d6bda70, argv=<value optimized out>) at connection.c:1291 #13 0x00007f3f9b6f04e8 in ldap_int_thread_pool_wrapper (xpool=0x16f36d0) at tpool.c:688 #14 0x0000003b6f2079d1 in start_thread () from /lib64/libpthread.so.0 #15 0x0000003b6eee8b6d in clone () from /lib64/libc.so.6 Crash can be reproduced by using data.mdb file on any host with the same slapd binaries. Also note contextCSN of DB became 'old' - it was actual on May 22 for both instances, when reset occured, but after start context CSN shows May 21 and 20. Also mdb_stat utility crashes on attempt to show FreeDB data: $ mdb_stat -f ./data Freelist Status Tree depth: 3 Branch pages: 7 Leaf pages: 817 Overflow pages: 0 Entries: 16995 Segmentation fault (core dumped)

1 0

(ITS#7861) Wrong entry count with MDB_DUPSORT databases
by h.b.furuseth＠usit.uio.no 27 May '14

27 May '14

Full_Name: Hallvard B Furuseth Version: mdb.master, 4b9aed26a5b1c0027b10d211c6e7270dbb1ade1c OS: Linux x86_64 URL: Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard mdb_cursor_put() does not always know if it'll be inserting a new item or not, e.g. when inserting in a sub-database. This was always wrong, but recent commits changed how it was wrong. Fix: Split 'insert' in 'insert_key' + 'insert_data'. Compute insert_data from mx_db.md_entries before and after the insert. In my UiO repo, branch mdb/todo-3: 02dd3865d5 [Rewritten] ITS#xxxx Fix MDB_db.md_entries. c6c78f71d3 [New] Tweak varname 'insert'. (Cosmetic patch which does not apply cleanly, I guess I should make an mdb/todo-4 branch where it is applied earlier.) Affects ITS#7834. mdb_cursor_del(, MDB_NODUPDATA) only subtracts 1 from md_entries when deleting a sub-page, instead of no of DUP entries. Fix: fa8e827026 [New,Squash] Fix md_entries in mdb_cursor_del:MDB_NODUPDATA.

1 0

(ITS#7860) [PATCH] correction to ldap_ava in ldap_get_dn.3
by ryan＠nardis.ca 26 May '14

26 May '14

Full_Name: Ryan Tandy Version: master/b22a614, RE24/d961650 OS: Debian unstable URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=38;bug=465024 Submission from: (NULL) (24.68.121.206) Hi, In Debian bug #465024, Philipp Hahn has provided the following patch, supplementing the change from ITS#5366: Index: openldap-2.4.39/doc/man/man3/ldap_get_dn.3 =================================================================== --- openldap-2.4.39.orig/doc/man/man3/ldap_get_dn.3 2014-02-21 00:12:24.000000000 +0100 +++ openldap-2.4.39/doc/man/man3/ldap_get_dn.3 2014-04-17 11:28:10.468925942 +0200 @@ -82,8 +82,8 @@ .ft B typedef struct ldap_ava { - char *la_attr; - struct berval *la_value; + struct berval la_attr; + struct berval la_value; unsigned la_flags; } LDAPAVA; It looks correct to me. (I assume the omission of la_private is intentional.) thanks, Ryan

1 0

Re: (ITS#7859) ldif processing issue with long lines
by hyc＠symas.com 26 May '14

26 May '14

mwarren(a)symas.com wrote: > Also, another issue has been reported where the length of LDIF lines is greater > by two than a specified 'ldif-wrap' definition when using slapcat. This appears to be the result of an intentional backward-compatiblility kludge. While the spec may have defaulted to 76 chars, the UMich code has always output 78 columns by default, so there's an offset built in to the LDIF output functions. This offset wasn't taken into account when the variable output width support was written. Probably we should just remove the kludge and define our default output width to 78 instead of pretending it's still 76. -- -- 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#7859) ldif processing issue with long lines
by mwarren＠symas.com 26 May '14

26 May '14

Full_Name: Mark Warren Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) A customer of ours has identified an issue with slapadd and lines right at the maximum length(4096 characters). Howard has taken a look and reports the following: I took a quick look at the slapadd issue; libldap/ldif.c is using an input buffer of size [LDIF_MAXLINE] which is 4096 characters. It uses fgets() to read the input. The problem is that fgets() always stores a terminating NUL character, which means the buffer can only accept an input of up to 4095 characters. The input line in question is "only" 4095 characters long, but in reality it also has a terminating newline, making it 4096. The end result, fgets() reads the data but leaves the newline in the input buffer since there's no room for it in the user buffer. Then the next call to fgets() returns just this newline all by itself, which signals to ldif_read_record that it's come to the end of the entry, and so it treats the next input line as a new entry even though it's supposed to be a continuation of the previous line. The simple fix here is to bump up the input buffer size by 1, to accommodate the terminating newline. Actually the buffer needs to be upped by 2, to allow for CR/LF line terminators. -- End Howard Quote -- Also, another issue has been reported where the length of LDIF lines is greater by two than a specified 'ldif-wrap' definition when using slapcat. Regards, Mark Warren

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2014