Winbindd Memory Leak Partial Fix

Esh, Andrew AEsh at tricord.com
Fri Oct 5 10:06:02 GMT 2001


I have a short fix to winbindd_users.c which will fix almost all of the
memory leakage which occurs when a user list is requested. There are similar
leaks in the group info as well, but those are still under review. I wanted
to get this fix out fast in order to address the most common problem with
lists. Remember, this leak can be produced by doing a "wbinfo -u" or a
"getent passwd". There may be much smaller leaks occurring when a single
user entry is requested; this fix does not address those.

The problem turned out to be a missing memory context destroy in
winbind_list_users, and in get_sam_user_entries. All the names being
converted from Unicode to ASCII in the for loops in the latter parts of
those functions were no longer in use, and were not being freed.

I had written "talloc_free", to take just the names out of the context list.
I thought at the time that the names were being allocated differently, and
so were not being freed when the rest of the data was being freed. When I
got done testing, I noticed that the size of the allocations in the context
list was exactly the same as the last few leaked blocks in the above named
functions. This means the context was effectively empty just from removing
the names, and what was left also needed to be freed. I took out my code,
and called "talloc_destroy" instead. The code still works, and no blocks are
being leaked as a result of the parsing code.

There is a leak from calling "domain_handles_open", and another single block
that I haven't dealt with yet. I will send another patch when I track those
down. Here's the diff with SAMBA_2_2 at the tip:

Index: winbindd_user.c
===================================================================
RCS file: /cvsroot/samba/source/nsswitch/winbindd_user.c,v
retrieving revision 1.3.4.4
diff -c -r1.3.4.4 winbindd_user.c
*** winbindd_user.c	8 Sep 2001 20:38:52 -0000	1.3.4.4
--- winbindd_user.c	5 Oct 2001 16:49:23 -0000
***************
*** 475,480 ****
--- 475,482 ----
  	ent->sam_entry_index = 0;
  	ent->got_all_sam_entries = (status != STATUS_MORE_ENTRIES);
  
+ 	talloc_destroy(ent->domain->sam_dom_handle.mem_ctx);
+ 
  	return ent->num_sam_entries > 0;
  }
  
***************
*** 503,508 ****
--- 505,514 ----
  
  	num_users = MIN(MAX_GETPWENT_USERS,
state->request.data.num_entries);
  	
+ 	if (state->response.extra_data != NULL) {
+ 	  free(state->response.extra_data);
+ 	}
+ 
  	if ((state->response.extra_data = 
  	     malloc(num_users * sizeof(struct winbindd_pw))) == NULL) {
  		return WINBINDD_ERROR;
***************
*** 683,688 ****
--- 689,696 ----
  				extra_data[extra_data_len++] = ',';
  			}   
  		} while (status == STATUS_MORE_ENTRIES);
+ 
+ 		talloc_destroy(domain->sam_dom_handle.mem_ctx);
          }
  
  	/* Assign extra_data fields in response structure */

---
Andrew C. Esh                mail:Andrew.Esh at tricord.com
Tricord Systems, Inc.
2905 Northwest Blvd., Suite 20        763-557-9005 (main)
Plymouth, MN 55441-2644 USA      763-551-6418 (direct)
http://www.tricord.com - Tricord Home Page

-------------- next part --------------
HTML attachment scrubbed and removed


More information about the samba-technical mailing list