Re: Very slow ldapserach

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Thursday, April 09, 2015 10:21 AM +0200 Saša-Stjepan Bakša 
<ssbaksa@gmail.com> wrote:
> And search for all still crashes openldap server
>
> ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub
> -a always -b dc=SPR objectClass=*
>
>
> 552641e7 >>> dnPrettyNormal: <dc=SPR>
> 552641e7 <<< dnPrettyNormal: <dc=SPR>, <dc=spr>
> ber_scanf fmt (m) ber:
> ber_scanf fmt ({M}}) ber:
> 552641e7 => mdb_search
> 552641e7 mdb_dn2entry("dc=spr")
> 552641e7 => mdb_dn2id("dc=spr")
> 552641e7 <= mdb_dn2id: got id=0x1
> 552641e7 => mdb_entry_decode:
> 552641e7 <= mdb_entry_decode
> 552641e7 search_candidates: base="dc=spr" (0x00000001) scope=2
> 552641e7 => mdb_equality_candidates (objectClass)
> 552641e7 => key_read
> 552641e7 <= mdb_index_read 10000000 candidates
> 552641e7 <= mdb_equality_candidates: id=-1, first=16, last=10000015
> Segmentation fault
>
>
> I must wait for 2.4.41 release then. In the mean time I will use LTB
> project build with HDB to see can I have that version in working state
> for my colleagues test suite.

Hi Sasa,

Thanks for checking.  Looks like there is some more work to do in this area 
before 2.4.41 releases.  I wil be asking you to do further testing in the 
near future.  If it were possible for you to provide me an example DB and 
your slapd configuration that replicates this behavior, it would help with 
a resolution.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration