#47780 Some VLV search request causes memory leaks
Closed: wontfix None Opened 8 years ago by nhosoi.

Some error cases such as timed out leak IDL.

Another known case is search result is successful, 0 entry found, with no VLV configured.


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.

{{{

56   *       be netative values.  OL (-1) is LDAP_SERVER_DOWN.  Thus, it's safe to

}}}
should be "negative"

otherwise, ack

Thanks, Rich! I fixed the typo...

Pushed to master:
832253e..1118cc9 master -> master
commit 1118cc9

Pushed to 389-ds-base-1.3.2:
c13feee..e9f86da 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit e9f86da

Pushed to 389-ds-base-1.3.1:
1a9e1d8..ff4c7a7 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit ff4c7a7b3f65589f93d88aadfcbe95976a9b31a9

Pushed to 389-ds-base-1.2.11:
0ee8496..bd0fe25 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit bd0fe25

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.2.11.30

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1112

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.

Metadata