[Patches] Preparation for tevent impersonation (part1)

[Jeremy Allison]

On Fri, Jun 15, 2018 at 02:26:53PM +0200, David Disseldorp via samba-technical wrote:
> On Fri, 15 Jun 2018 13:08:27 +0200, Volker Lendecke via samba-technical wrote:
> 
> > On Fri, Jun 15, 2018 at 09:25:08AM +0200, Volker Lendecke via samba-technical wrote:
> > > If talloc_tos() is no longer en vogue, we need a similarly concise
> > > abstraction.  
> > 
> > Another one that just came in:
> > 
> > https://lists.samba.org/archive/samba-technical/2018-June/128427.html
> 
> If you want to start digging into individual issues then I'll bring up
> 5fe76a5474823ed7 (https://bugzilla.samba.org/show_bug.cgi?id=12836).
> This isn't a minor leak in an error path, it's a use after free brought
> on by the talloc stackframe garbage collector cleaning up memory which
> was erroneously allocated on talloc_tos(). Continued use of talloc_tos()
> while the rest of the codebase transitions to being event-based and
> asynchronous will only result in more such cases IMO.

Great ! That's *exactly* the kind of talloc-misuse bug we want
to see. smbd *crashes*, rather than leaking stuff onto a long-lived
context which only gets caught days/weeks/months(?) after the
real problem happened.

The ldb code has had many problems with such long-term memory leaks.

It's no coincidence that this was written by engineers who
also didn't like talloc_tos() (not trying to pass judgement
here, that is a perfectly valid opinion to have, just one I
don't share).

In fact this does give a good experiment with control. If
ldb is kept talloc_tos()-free, then after a year or so
we can do analysis on how many long-term memory leak bugs
we have had to fix in this code vs. code containing talloc_tos().

Jeremy.