[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7715) SIGBUS when mdb is configured with writemap



hyc@symas.com wrote:
> Željko NejaÅ¡miÄ? 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 that
> 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=manager,dc=example,dc=com -w secret -b 
ou=people,dc=example,dc=com -e 
object=xx.txt,rdn='uid:[A=INCRNNOLOOP(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 ***
======= Backtrace: =========
/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 more 
reliable way to reproduce the issue that would help. Perhaps using the client 
in test060.

> All subsequent runs give the same result. Still looking into this; getting
> away from the Ubuntu bundled libldap will probably help.
>>
>>
>> Zeljko
>>
>>
>> On Wed, Oct 2, 2013 at 11:34 AM, <hyc@symas.com <mailto:hyc@symas.com>> wrote:
>>
>>      nejasmicz@gmail.com <mailto:nejasmicz@gmail.com> wrote:
>>       > Full_Name: Željko Nejašmi&#263;
>>       > Version: latest git pull of OPENLDAP_REL_ENG_2_4
>>       > OS: RedHat 6.3
>>       > URL:
>>       > Submission from: (NULL) (213.147.123.33)
>>       >
>>
>>       > Hardware underneath all of that is:
>>       >      1) HP ProLiant BL460c Gen8, dual Xeon E5-2658 with attached
>>      storage blade
>>       > D2200sb with SSD raid, 256GB RAM -- RedHat 6.3 tests
>>       >      2) Intel server blade S2400BB, dual Xeon E5-2403, 48GB RAM --
>>      Ubuntu 12.04
>>       > tests
>>       >
>>       > If anything more is required to assist you in troubleshooting, please
>>      let me
>>       > know.
>>
>>      Can you also post the gdb output for "bt 5 full" ?
>>       >
>>       >
>>       > Zeljko
>>       >
>>       >
>>



-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/