Ticket #47780 - Some VLV search request causes memory leaks
Fix description:
. Modified idl_free interface as follows so that passed idl is cleared
with NULL once the IDList is successfully freed.
-idl_free(IDList *idl)
+idl_free(IDList **idl)
This change is used to clean up search candidates when ldbm_back_
search_cleanup (ldbm_search.c) is called as an error return. The
cleanup function frees the search candidates when it's not NULL and
it's not assigned to sr_candidates field in the search result. This
fixes a memory leak when VLV/Sort op fails.
. ldbm_back_search_cleanup (ldbm_search.c) calls slapi_send_ldap_result
if an ldap error is passed to the function. The logic used to be
"if (ldap_result>=LDAP_SUCCESS)", which is based upon that mozldap
return codes are all positive. Supporting openldap library, there
is a chance to get a negative return code (e.g. LDAP_PARAM_ERROR ==
-9). This patch supports the negative return codes, as well.
. In ldbm_back_search (ldbm_search.c) vlv_filter_candidates could
ruturn errors such as and LDAP_TIMELIMIT_EXCEEDED, LDAP_ADMINLIMIT_
EXCEEDED. The search results are supposed to be returned to the
client with the error code if the control is not critical. The code
is added.
. The VLV operation stores the result in vlv_response_control.result
in ldbm_back_search (ldbm_search.c), which occurs at 3 places, vlv_
filter_candidates, sort_candidates and vlv_trim_candidates_txn.
The return code from the latter calls used to override the former
return code. This patch fixes it to respect the former return code.
https://fedorahosted.org/389/ticket/47780
Reviewed by rmeggins@redhat.com (Thank you, Rich!!)
(cherry picked from commit 1118cc9b61a60c704250080d6af8785e4f8d28af)