--001a11c253c0f33b8604e7d59850 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 2, 2013 at 6:43 PM, hyc@symas.com wrote:
hyc@symas.com wrote:
=C5=BDeljko Neja=C5=A1mi=C4=87 wrote:
Here you go http://hastebin.com/fukecejuje.tex
Interestingly enough, I got the same result as you on an initial
compile/run
of slapd. Unfortunately, with optimization, the backtrace wasn't all th=
at
useful. Recompiling back-mdb with just -g, no optimization, gets a
different
result though - slapd is fine, and ldclt dies with a heap corruption or double-free.
And now I cannot reproduce the original SIGBUS at all. But still getting various crashes in ldclt.
ldclt -h localhost -p 9011 -D cn=3Dmanager,dc=3Dexample,dc=3Dcom -w secre=
t -b
ou=3Dpeople,dc=3Dexample,dc=3Dcom -e object=3Dxx.txt,rdn=3D'uid:[A=3DINCRNNOLOOP(200000;999999;6)]' -e add,commoncounter -I 68 ldclt version 4.23 ldclt[30207]: Starting at Wed Oct 2 09:39:10 2013
*** glibc detected *** ldclt: double free or corruption (fasttop): 0x00007fc2180021e0 *** =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc223ff9b96] /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x142d1)[0x7fc224f0b2d1] /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x1ae74)[0x7fc224f11e74] /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_Malloc+0x49)[0x7fc224f0d0b9] /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x129f4)[0x7fc224f099f4] /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x12068)[0x7fc224f09068] /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_vsmprintf+0x38)[0x7fc224f09b28] /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_smprintf+0x8c)[0x7fc224f09bec] ldclt(+0x663a)[0x7fc22556663a] ldclt(+0x74a4)[0x7fc2255674a4] ldclt(+0x9d48)[0x7fc225569d48] ldclt(threadMain+0x329)[0x7fc2255735d9] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc224341e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc22406ecbd]
Without any other clues, this feels like ASLR is messing with us but that=
's
just a wild guess. I can no longer reproduce the SIGBUS in slapd regardless of compile options, while ldclt itself keeps dying. If you can find some mor=
e
reliable way to reproduce the issue that would help. Perhaps using the client in test060.
I ran the whole test suite for mdb, and as far as I can see, every test returned OK.
Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 firing to openldap on RH 6.3: ldapadd -h 172.17.101.150 -p 389 -D "cn=3Dadmin,dc=3Dtest" -w test -f test.= ldif -- ldif file is the same as the previous ldclt command. Doubt it matters, but the ldif file is 1M adds.
On the RH box: - compiled openldap with -g -O0 and previously used flags gdb `find /root/openldap/ -type d -printf '-d %p '` --args /opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
gdb output: bt -- http://hastebin.com/hefikekaxi.sh bt 10 full -- http://hastebin.com/vudocosuka.sh
I am begging to doubt that the problem could be on my end as the bt seems to point to schema problems (although, I haven't analyzed it in great detail yet).
Zeljko
--001a11c253c0f33b8604e7d59850 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">On Wed, Oct 2, 2013 at 6:43 PM, <span dir=3D"ltr"><<a href=3D"m= ailto:hyc@symas.com" target=3D"_blank">hyc@symas.com</a>></span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli= d;padding-left:1ex">
<div><a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc@symas.com</a> w= rote:<br> > =C5=BDeljko Neja=C5=A1mi=C4=87 wrote:<br> >> Here you go <a href=3D"http://hastebin.com/fukecejuje.tex" target= =3D"_blank">http://hastebin.com/fukecejuje.tex</a><br> ><br> > Interestingly enough, I got the same result as you on an initial compi= le/run<br> > of slapd. Unfortunately, with optimization, the backtrace wasn't a= ll that<br> > useful. Recompiling back-mdb with just -g, no optimization, gets a dif= ferent<br> > result though - slapd is fine, and ldclt dies with a heap corruption o= r<br> > double-free.<br> <br> </div>And now I cannot reproduce the original SIGBUS at all. But still gett= ing<br> various crashes in ldclt.<br> <div><br> ldclt -h localhost -p 9011 -D cn=3Dmanager,dc=3Dexample,dc=3Dcom -w secret = -b<br> ou=3Dpeople,dc=3Dexample,dc=3Dcom -e<br> object=3Dxx.txt,rdn=3D'uid:[A=3DINCRNNOLOOP(200000;999999;6)]' -e a= dd,commoncounter<br> -I 68<br> ldclt version 4.23<br> </div>ldclt[30207]: Starting at Wed Oct =C2=A02 09:39:10 2013<br> <div><br> *** glibc detected *** ldclt: double free or corruption (fasttop):<br> </div>0x00007fc2180021e0 ***<br> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D<br> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc223ff9b96]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x142d1)[0x7fc224f0b2d1]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x1ae74)[0x7fc224f11e74]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_Malloc+0x49)[0x7fc224f0d0b9]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x129f4)[0x7fc224f099f4]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x12068)[0x7fc224f09068]<br> /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_vsmprintf+0x38)[0x7fc224f09b28]<br=
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_smprintf+0x8c)[0x7fc224f09bec]<br> ldclt(+0x663a)[0x7fc22556663a]<br> ldclt(+0x74a4)[0x7fc2255674a4]<br> ldclt(+0x9d48)[0x7fc225569d48]<br> ldclt(threadMain+0x329)[0x7fc2255735d9]<br> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc224341e9a]<br> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc22406ecbd]<br> <br> Without any other clues, this feels like ASLR is messing with us but that&#= 39;s<br> just a wild guess. I can no longer reproduce the SIGBUS in slapd regardless= of<br> compile options, while ldclt itself keeps dying. If you can find some more<= br> reliable way to reproduce the issue that would help. Perhaps using the clie= nt<br> in test060.</blockquote><div><br></div><div>I ran the whole test suite for = mdb, and as far as I can see, every test returned OK.</div><div><br></div><= div>Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 f= iring to openldap on RH 6.3:<br>
</div><div>ldapadd -h 172.17.101.150 -p 389 -D "cn=3Dadmin,dc=3Dtest&q= uot; -w test -f test.ldif -- ldif file is the same as the previous ldclt co= mmand. Doubt it matters, but the ldif file is 1M adds.</div></div><br></div=
<div class=3D"gmail_extra">On the RH box:</div><div class=3D"gmail_extra">-= compiled openldap with -g -O0 and previously used flags</div><div class=3D= "gmail_extra"> gdb `find /root/openldap/ -type d -printf '-d %p '` --args /opt/ope= nldap/libexec/slapd -h "ldap:/// ldapi:///" -F /opt/openldap/etc/= openldap/slapd.d -g openldap -u openldap -d 0<br></div><div class=3D"gmail_= extra">
<br></div><div class=3D"gmail_extra">gdb output:</div><div class=3D"gmail_e= xtra">bt --=C2=A0<a href=3D"http://hastebin.com/hefikekaxi.sh" target=3D"_b= lank">http://hastebin.com/hefikekaxi.sh</a></div><div class=3D"gmail_extra"=
bt 10 full --=C2=A0<a href=3D"http://hastebin.com/vudocosuka.sh" target=3D=
"_blank">http://hastebin.com/vudocosuka.sh</a></div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I am beggin= g to doubt that the problem could be on my end as the bt seems to point to = schema problems (although, I haven't analyzed it in great detail yet).<= /div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><= div class=3D"gmail_extra">Zeljko</div> </div>
--001a11c253c0f33b8604e7d59850--
-
nejasmicz＠gmail.com