[PATCH] Add stackframes to public libsmbclient functions
Volker.Lendecke at SerNet.DE
Mon Nov 19 14:54:19 GMT 2007
On Mon, Nov 19, 2007 at 09:40:09AM -0500, Derrell Lipman wrote:
> The concept has merit. I wouldn't remove it quite yet. Why not use
> it as a debugging tool. If every layer is _supposed_ to free its
> locally-allocated memory, then why not have debug capability to
> display -- at any layer -- memory which was allocated "on the stack"
> that should have been freed earlier. Instead of using it as a way for
> the higher layers to "fix" a bug in the lower layer, why not use it as
> a way to request a list (including file name and line number of
> allocation) of memory that didn't get freed. That way the bugs get
> fixed where they should, but you retain the cleanliness of your new
Well, if no function is allowed to leak memory on
talloc_tos(), then we should get rid of talloc_tos() at all.
Not having to pass an explicit temporary talloc context was
the whole point of it. If that defined and intended memory
leak is generally seen as a bug, talloc_stackframe() needs
to go because it was intended to enable it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20071119/cfa40103/attachment.bin
More information about the samba-technical