Samba 2.0.7 mem leaks, continued

[acherry at pobox.com]

 > One small observation: Based on Andrew's description, it sounds like
 > both affected sites might be able to temporarily work around their
 > problem by running smbd out of inetd, rather than as a standalone
 > daemon, on their production servers? That way you get a fresh smbd
 > process, which only ever parses the config file once, for each new
 > connection.
 > 
 > I use Samba 2.0.7 on Solaris 2.6 without problems, and it so happens
 > that I'm using inetd style, which might explain why I've not seen the
 > memory leak symptoms here.

That makes sense given the behavior I've been seeing -- the parent smbd
daemon process grows over time, and newly spawned children inherit the 
size.

Our workaround right now is to use 2.0.6, which so far hasn't shown
any evidence of leakage.  Running smbd from inetd isn't an option in
our case, since starting/stopping Samba happens from high-availability 
scripts and relies on command line switches passed from those scripts.

Since the dbx leak checking I did seemed to point to the
hash_table_init() function in lib/hash.c, I did some poking around to
see what the problem was.  At least one problem is that there's a
hash_clear() function to free up the memory used by a table, but it
never gets referenced anywhere. :-) Send the smbd daemon enough HUP
signals and this will become noticeable as the old stat_cache is
thrown away each time (more noticeable in the long run).

I've gotten around this by running hash_table_clear(&stat_cache) in
smbd/filename.c just before running hash_table_init().  But even after
doing that, the smbd daemon process still seemes to be gaining about
8K per hour (though an improvement over before)... I'm not yet sure
where that memory is going -- I haven't been able to reproduce it in a 
test environment, and I want to keep the testing/experimentation off
of our production server.

If I find anything else out, I'll let you know.

-Andrew