[Patches] Preparation for tevent impersonation (part1)
ddiss at samba.org
Fri Jun 15 12:26:53 UTC 2018
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:
If you want to start digging into individual issues then I'll bring up
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.
> I'm not saying that we should use talloc_tos() deep inside ldb, but if
> you want to ditch it, please provide something of similar
> functionality to avoid hickups like the ones Andrej found. That is
> precisely the kind of memory leak that I've tried to prevent with
> talloc_tos(). We NEED something like that. Please consider these cases
> when you say that talloc_tos() needs to be avoided.
talloc provides a simple API which is perfectly capable of being used to
produce leakless code. I believe integrating memory tracking tools such
as valgrind and talloc_report_full() into regular CI would be a better
way forward here.
More information about the samba-technical