[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
--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--