[QUICK] talloc bugs

[Sam Liddicott]

Hi Tridge

* tridge wrote, On 29/06/09 12:58:
> Hi Sam,
>
>  > However depending on the meaning of your clause "disallow direct
>  > talloc_free() of a pointer that has outstanding references" this
>  > constraint on talloc_free could lead instead to memory leaks.
>
> First off I'd propose that for a test patch we abort() if you
> talloc_free() a pointer with a reference. Then we can run 'make test'
> and see just how often this happens. I think it will be very rare, and
> we may even find it doesn't happen at all outside of the talloc test
> suite.
>   
I'll do that (just for you).
..

> If you call talloc_free(p1) or talloc_free(p2) then you will get the
> current behaviour, as there is no ambiguity. 
>
> If you call talloc_unlink(p1, c1) or talloc_unlink(p2, r1) then it
> will free the appropriate parent/reference.
>
> Whether we can live with this is yet to be seen. We need to try it,
> see if we have come to depend on the ambiguity, and if we have then
> deal with it.
>
> My guess is we have very few bits of code that depend on this
> ambiguity.
>   
Most certainly there are very few bits of code or we would have run
against this more often than I have.

However at issue isn't whether or not samba (as it is) can deal with it
(as clearly it "mostly" can) but what talloc should be in the context of
a system library also used by non-samba programs.

Calling talloc_free(ptr) is legitimate for simple programs, it is
convenient that talloc "remembers" the parent pointer.
I'm trying to let this use co-exist with talloc_reference whether or not
we remove talloc_free from Samba.

(Taking the broad view for talloc as a system library)

I'll post the test results when I have them.

Sam