https://bugs.openldap.org/show_bug.cgi?id=9098

--- Comment #18 from maxime.besson@worteks.com maxime.besson@worteks.com --- Hi,

In thread 1 at #4 :

i and candidates[i] are optimized out, but the disasembly if that assert line shows a 0x10(%r13),%eax that leads me to believe that candidates[i] is in $r13 at that time:

(gdb) print *((SlapReply *)$r13) $90 = {sr_type = REP_RESULT, sr_tag = 3, sr_msgid = -1, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0}

I can't be exactly sure about 'i', but poking around memory makes be believe that it's 5 too.

In thread 8 at #9:

(gdb) print candidate $85 = 5 (gdb) print candidates[candidate] $86 = {sr_type = 4294967295, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x25, sr_ctrls = 0x7f007061646c, sr_un = {sru_search = {r_entry = 0x7f4184000078, r_attr_flags = 32, r_operational_attrs = 0x25, r_attrs = 0x7f005f706374, r_nentries = -2078873856, r_v2ref = 0x20}, sru_sasl = { r_sasldata = 0x7f4184000078}, sru_extended = {r_rspoid = 0x7f4184000078 "\320|\033\204A\177", r_rspdata = 0x20}}, sr_flags = 133}

The other stack traces I collected however do not seem to show an interaction with ldap_sasl_bind

I should be able to deploy a patched slapd 2.4.48 (or why not 2.4.49) if you send me a diff.