On 9 April 2015 at 02:37, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, April 08, 2015 8:51 PM +0200 Saša-Stjepan Bakša < ssbaksa@gmail.com> wrote:
I am sorry for this mistake with answering to you and not to the group.
It was unintentional mistake.
Ok, I will check ITS#7657.
Please try current RE24 code. It is believed the fixes for ITS#8011 which are scheduled to be part of the 2.4.41 relase should resolve the issue.
Thanks,
Quanah
At 8:00 local time: git checkout OPENLDAP_REL_ENG_2_4 git pull
Build + test
root@test:~# date; ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub -a always -b msisdn=385212000009,dc=MSISDN,dc=SPR objectClass=*; date *Thu Apr 9 08:22:46 CEST 2015* # extended LDIF # # LDAPv3 # base <msisdn=385212000009,dc=MSISDN,dc=SPR> with scope subtree # filter: objectClass=* # requesting: ALL # ----- cut------ # search result search: 2 result: 0 Success
# numResponses: 9 # numEntries: 8 *Thu Apr 9 08:23:38 CEST 2015*
Nothing changed yet - 52 seconds
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.
Br
Sasa