Hello, we tested this (HEAD code):
- ITS 6565 seems to be fixed: Chaining works now with correct search
base.
- If the target server of the chaining is not reachable we get "no such
object", followed by a SIGSEV (core dump). Stack Trace:
#0 0x0000000400040004 in ?? () #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:436 #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:621 #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at chain.c:1132 #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at backover.c:237 #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:402 #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:476 #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, rs=0x7ffff1f70940) at referral.c:118
0x0000000400040004 is the address referenced in op->o_callback->sc_cleanup(op,rs) .
Thanks for the report. It would be useful to know how that memory became stale or dangling. Could you run slapd under valgrind and report any error message related to accessing that memory? Thanks, p.
I've checked a simple configuration (global instance of chain overlay; request for non existing entry, resulting in slapd returning the default referral), and nothing strange appeared (the offending instruction is executed). The issue might be specific to your configuration. You'll probably need to post more details.
p.