Bug 5419 - memory leak in ads_do_search_all_args() when enumerating 1000s of entries
Summary: memory leak in ads_do_search_all_args() when enumerating 1000s of entries
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.2.0
Hardware: All Linux
: P3 major
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-25 20:29 UTC by Steven Danneman
Modified: 2008-04-26 02:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Danneman 2008-04-25 20:29:14 UTC
Repro:

1) Start winbindd with caching turned off

# winbindd -n

2) Join to a domain with thousands of groups

3) Repeatedly enumerate all groups

# for i in {1..100}; do wbinfo -g; done

Result:

The memory usage of the child process spawned to handle requests for the domain
with thousands of groups will slowly increase in memory size.

Cause:

The ads_do_search_all_args() function attempts to string together several LDAPMessage structures, returned across several paged ldap requests, into a single LDAPMessage structure.  It does this by pulling entries off the second
LDAPMessage structure and appending them to the first via the OpenLDAP specific
ldap_add_result_entry() call.

The problem with this approach is it skips non-entry messages such as the result, and controls.  These messages are leaked.

Solution:

The short term solution as discussed with Volker on IRC (http://samba.sernet.de/irclog/2008/04/20080426-Sat.log) is to replace the ads_*_entry() calls with ads_*_message() calls so we don't leak any messages.

This fixes the leak but doesn't remove the dependence on the OpenLDAP specific implementation of ldap_add_result_entry().  This needs to be fixes by some restructuring of the callers to this function, possibly making them iterate the multiple paged LDAPMessage structs themselves.

Backport:

This bug/fix should also be backported to the 3.0.x branch.
Comment 1 Volker Lendecke 2008-04-26 02:27:33 UTC
Pushed to 3-2 with fe9f48bfe8 and to 3-0 with ce475f86a2

Thanks,

Volker