and: dangling talloc references and inconsistencies in the talloc
tridge at samba.org
tridge at samba.org
Fri Jan 23 03:11:24 GMT 2009
> Also, the test I supplied called "test_dangling_loop" shows a bug,
> described just above the test definition.
I don't see it as a bug. The test is an extension of a simple
loop. The simple loop
The diagram is supposed to show that p1 is a parent of p2, but p2 is a
parent of p1. So what do we do if you talloc_free(p1) ? If we follow
your rules then the free will do nothing. You can't get rid of that
So (quite deliberately) I added code so that a talloc_free() on a loop
like that does free the loop. That seemed to be the only sensible
thing to do.
Viewed using the print format that talloc_report_full() uses, the
memory looks like this:
full talloc report on 'null_context' (total 51 bytes in 7 blocks)
root contains 51 bytes in 6 blocks (ref 0) 0x20380c0
r1 contains 25 bytes in 2 blocks (ref 0) 0x20381e0
reference to: p2
p1 contains 26 bytes in 3 blocks (ref 1) 0x2038120
p2 contains 25 bytes in 2 blocks (ref 1) 0x2038180
reference to: p1
then we free p1, and we end up with this:
full talloc report on 'null_context' (total 2 bytes in 4 blocks)
root contains 2 bytes in 3 blocks (ref 0) 0x20380c0
r1 contains 2 bytes in 2 blocks (ref 0) 0x20381e0
p2 contains 1 bytes in 1 blocks (ref 0) 0x2038180
I think that is quite sensible. We had a loop, which got removed, but
one part of the loop had an external reference, and that part of the
loop got saved, as a child of the pointer that referenced it.
> I tried to consider if there was any way (without my full blown
> solution) ....
What is your proposed full blown solution? I may well have just missed
it in the various emails. Do you have a working set of code which
would replace talloc, or a testsuite showing how you think it might be
used? That might help me understand what you are pushing for.
More information about the samba-technical