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
--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
openldap-technical@openldap.org