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!