This bug is to do with the telldir() function, which has a memory leak in it.

Recently I experienced the same problem with netbsd 3.0 and openbsd 3.8/3.9, 
and there is a patch in openbsd current ( which works with 3.9/3.9 from 
memory ), only a few days after the bug was found.

Pretty poor that is has been broken for so long, even when a patch is 
available.


On Monday 26 June 2006 21:40, Mark Cullen wrote:
> Stephen Borrill wrote:
> > On Mon, 26 Jun 2006, Mark Cullen wrote:
> >> I am experiencing a memory leak of some sorts related to Samba. I
> >> strongly believe it is related to the the PR [1] which is still
> >> 'Open'. I have run the included test program from the said PR, and I
> >> get the following output:
> >
> > [snip]
> >
> >> Is there any plans to fix this? There is a patch included, but it was
> >> filed for 1.6 by the looks of it. I'm not sure if it'll work with 3.x?
> >>
> >> As it stands, Samba is fairly unusable for me because of this, or at
> >> least I think it's this. I never had the problem on FreeBSD, but that
> >> was with Samba 3.0.21b, I am now using 3.0.22. I've mailed the Samba
> >> lists, but I am sure it's related to this bug.
> >
> > I had a few email exchanges with Jeremy Allison about this back in
> > October last year, but I think my emails got swamped by all his other
> > Samba-related mails. :-)
> >
> > We don't see it at most sites which, at the time, I thought was down to
> > security = domain vs security = server (and Jeremy suggested there was a
> > passdb leak too). It was also not clear what triggered it (NetBSD
> > 1.6.2/Samba 3.0.10 was fine, NetBSD 2.0_STABLE/Samba 3.0.14 was not). It
> > was clear, however, it was a NetBSD-specific problem.
> >
> > I agree that when you hit this memory leak, Samba is unusable (processes
> > grow pretty rapidly and start running out of data space and swap). It
> > would be great if this is the cause of the problem.
> >
> > Odd that this has not been fixed - is the patch particularly contentious?
>
> Hi Stephen,
>
> It is a rather odd problem indeed, and highly annoying! I'm actually
> using security = user, so I don't think it's that :-) It could of course
> be totally unrelated to this NetBSD bug, but the fact it's increasing
> with directory refreshes makes me want to guess it is. But then it's
> also very strange that everyone isn't experiencing this behaviour!
>
> That's exactly what is happening with me. It grows and grows, and
> eventually it'll reach some kind of limit... and Samba will just plain
> stop responding to the clients requests filling the logs with:
>
> [2006/06/25 22:03:48, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4896 bytes
> [2006/06/25 22:03:48, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4896 bytes
> [2006/06/25 22:03:48, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4896 bytes
> [2006/06/25 22:03:58, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4136 bytes
> [2006/06/25 22:03:58, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4136 bytes
> [2006/06/25 22:03:58, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4136 bytes
> [2006/06/25 22:03:58, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4136 bytes
> [2006/06/25 22:03:58, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4136 bytes
> [2006/06/25 22:03:59, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4120 bytes
> [2006/06/25 22:03:59, 0] lib/util.c:Realloc(969)
>    Memory allocation error: failed to expand to 4120 bytes
>
> Until I kill the offending smbd process (it happens on a sort of
> 'per-user' basis). But of course, as I am working on the network drive
> most of the time, killing the smbd process makes Windows go in to a
> little bit of a frenzy, which then result in me having to either restart
> or attempt to logoff and log back on again ;)
>
> I am now setting up a test box again, and I am rebuilding with that
> patch applied. The patch still applies cleanly apart from the dirent.h
> patch. Only 2 of 3 'hunks' applied cleanly to that.
>
> @@ -92,7 +106,7 @@
>   void rewinddir __P((DIR *));
>   #if defined(_XOPEN_SOURCE) || defined(_NETBSD_SOURCE)
>   void seekdir __P((DIR *, long));
> -long telldir __P((const DIR *));
> +long telldir __P((DIR *));
>   #endif /* defined(_NETBSD_SOURCE) || defined(_XOPEN_SOURCE) */
>   #if defined(_NETBSD_SOURCE)
>   DIR *__opendir2 __P((const char *, int));
>
> That part didn't apply, but that's no biggie really -- I just changed
> the line manually for now! I shall report back soon on the outcome,
> hopefully. I have run in to a problem with my ftp-proxy set up which is
> delaying me from fetching Samba on the test machine. Darn!