[389-devel] Please review: [389 Project] #47780: Some VLV search request causes memory leaks

Noriko Hosoi nhosoi at redhat.com
Thu May 15 20:58:24 UTC 2014


https://fedorahosted.org/389/ticket/47780

https://fedorahosted.org/389/attachment/ticket/47780/0001-Ticket-47780-Some-VLV-search-request-causes-memory-l.patch

  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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-devel/attachments/20140515/7f811038/attachment.html>


More information about the 389-devel mailing list