Patch for memory leak in vfs_defaults.c

Timur I. Bakeyev timur at com.bat.ru
Sat Apr 7 02:03:53 UTC 2018


On 7 April 2018 at 01:22, Jeremy Allison <jra at samba.org> wrote:

> On Sat, Apr 07, 2018 at 12:50:48AM +0200, Timur I. Bakeyev via
> samba-technical wrote:
> >
> > Yes, while the fix is trivial by itself, it took a lot of time to locate
> > the leak and Andrew did a tremendous work to nail it and fix.
>
> Absolutely ! That's why I want his name on it - as I'm the one
> who introduced the bug in the first place, I certainly shouldn't
> be the author :-).
>
> > Finding the leak also showed us that there is no good tooling to track
> > memleaks in Samba, at least on FreeBSD. Both dmalloc and valgrind failed
> us
> > on various reasons and only jemalloc helped to confirm at that point,
> that
> > the right place was spotted.
>
> Did valgrind not catch this ? That would have seemed the natural
> tool to find the problem.
>

It possibly should, but `valgrind` on FreeBSD seems to be a derivation of
the original valgrind. At least all I got with `smbd -i` was a coredump :(

Well, if just supplying `-d` flag coredumps it - you can't expect much :)

But I was more surprised that despite having some hooks for dmalloc in the
Samba code I didn't get much results from it - it just didn't catch the
memleaks, showing only subset of memory allocations.

At least jemalloc did it's job right after some fiddling, but at that point
Andrew already spotted the offending code with his sharp eye :) So we just
confirmed that memory was leaking in getcwd():

Total: 13263634 B 11413504 86.1% 86.1% 11413504 86.1% getcwd 994829 7.5% 93
.6% 994829 7.5% _pthread_attr_getaffinity_np 716336 5.4% 99.0% 716336 5.4% 0
x000000080580029c 98560 0.7% 99.7% 98560 0.7% asn1_strerror
....

With best regards,
Timur Bakeyev.


More information about the samba-technical mailing list