Musings on talloc and talloc_free

[Volker Lendecke]

On Mon, Jan 12, 2009 at 04:22:27PM -0000, Sam Liddicott wrote:
> 1. talloc free should never be called more than once per allocation,
> because it becomes to hard to be sure who the second owner is.

Wait a second -- how is it possible to have two owners
assuming nobody calls talloc_reference()? I must have
completely misunderstood talloc_steal (or the s3 version of
it, talloc_move). I always thought it transfers ownership
and does not duplicate it.

> 2. that talloc_steal should never happen secretly but be a documented
> part of whatever function invokes talloc_steal() as part of it's operation.
> 3. talloc_steal should never be directly called after a talloc_free (OK
> internal to talloc)

Again -- doing *anything* to a pointer after having called
talloc_free on it is just a plain bug.

> 4. When talloc_free is called after talloc_steal it had better be in the
> context of the new owner - to be safe, why not just use talloc_unlink to
> prove it?

I don't get what you mean by "in the context of the new
owner". You call talloc_free() on a pointer. Where
is the context??

> 1. talloc_free (when not invoked internally) should raise an error if
> called more than once on the same allocation. Any code that does this

Calling talloc_free on a pointer twice just can't happen.
It's a bug. Period. That's why we have the TALLOC_FREE macro
in Samba 3. It NULLs out the pointer so that you get the
nice core dump error message on the second talloc_free call.

> "legitimately" because it "knows" who the second reference is, is both

You said on irc that talloc_reference is just innocent. From
that I understood that you don't have to use it to generate
all the hell you describe here. So I don't really know where
the second reference you describe comes from, unless I've
completely misunderstood talloc_steal so far.

Can you show us some small pieces of sample code that
demostrate your points?  

Thanks,

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20090112/8c388f56/attachment.bin