CVS update: samba/source/rpc_server

Andrew Bartlett abartlet at samba.org
Wed Jul 9 05:35:59 GMT 2003


On Wed, Jul 09, 2003 at 05:30:02AM +0000, Jeremy Allison wrote:
> On Wed, Jul 09, 2003 at 01:46:57AM +0000, Andrew Bartlett wrote:
> > On Wed, Jul 09, 2003 at 12:23:42AM +0000, jra at samba.org wrote:
> > > 
> > > Date:	Wed Jul  9 00:23:42 2003
> > > Author:	jra
> > > 
> > > Update of /data/cvs/samba/source/rpc_server
> > > In directory dp.samba.org:/tmp/cvs-serv7118/rpc_server
> > > 
> > > Modified Files:
> > >       Tag: SAMBA_3_0
> > > 	srv_samr_nt.c 
> > > Log Message:
> > > Get rid of DISP_USER_INFO/DISP_GROUP_INFO as they serve no useful
> > > purpose. Replace with an array of SAM_ACCOUNT/DOMAIN_GRP entries.
> > > ZERO struct's in smbd/uid.c stops core dumps when sid_to_XX
> > > functions fail. Getting ready to add caching.
> > > Jeremy.
> > 
> > Can we please make that array SAM_ACCOUNT** not SAM_ACCOUNT*?
> > 
> > Currently, we call pdb_free_sam() on a pointer into the array.
> > 
> > Now it happens that at the moment, we are using a talloc()ed SAM_ACCOUNT,
> > and it 'knows' not to free() the pointer.  We also 'loose' the original
> > allocated space, and do an implicit memcpy() into the array.  
> 
> I know. I looked at this code very carefully before
> committing it, and also ran it through valgrind. It
> will not leak memory, it will not lose the space as
> it is going via a tdb.

It's not leaking memory becouse it was allocated on the talloc context.  
But the memory from the original SAM_ACCOUNT is not refereced, except by
the talloc context.

> I am happy with the code as it is.

My main problem is with calling pdb_free_sam() on a pointer not created by
pdb_init_sam() - it breaks the abstraction of the SAM_ACCOUNT.

Would you mind if I cleaned up that code to handle this?

Andrew Bartlett



More information about the samba-technical mailing list