[QUICK] talloc bugs
sam at liddicott.com
Mon Jun 29 06:52:59 MDT 2009
* 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
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
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.
More information about the samba-technical