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