Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)

[Dina_Fine at Dell.com]

Hello Jeremy
The leak will not be noticeable for the main samba flow customers.
You see, we added additional samba processes (forked from the parent) which monitors the samba children death and will clean the clients state (byte-range locks, oplocks and such) in our distributed file system.
This process will display a message on every dead samba child process.
So the test which caused the below bug to leak a lot of memory is to run in loop cifs mount command with a non-existing user to a non-existing share (samba creates a new samba child processes for each mount attempt)

But the bug will be noticeable for us not only in the above scenario.
We have diagnostic procedure on our customers clusters. The customer can execute diagnostic command from the cluster CLI. The diagnostic will set a high debug level on samba processes, will take tcpdumps, strace when needed and such and then will send all the log files/traces to us.
In such a case when samba debug level is high, a *lot* of messages are printed to the log and memory leaks very fast.

Dina Fine


> -----Original Message-----
> From: Jeremy Allison [mailto:jra at samba.org]
> Sent: 30 November, 2011 22:17
> To: Jeremy Allison
> Cc: Fine, Dina; samba-technical at lists.samba.org
> Subject: Re: Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)
> 
> On Wed, Nov 30, 2011 at 12:05:42PM -0800, Jeremy Allison wrote:
> > On Wed, Nov 30, 2011 at 01:12:21PM +0000, Dina_Fine at Dell.com wrote:
> > > Hello
> > >
> > > We noticed a big memory leak when running different load testing tools especially
> when debug level was increased.
> > > The analyze led us to dbghdrclass function
> (/vobs/vendor/smb/source3/lib/debug.c), the following code:
> > > if( lp_debug_prefix_timestamp() ) {
> > >                             (void)Debug1( "[%s, %2d%s] ",
> > >                             current_timestring(talloc_tos(),  lp_debug_hires_timestamp()),
> level, header_str);
> > >                         } else {
> > >                             (void)Debug1( "[%s, %2d%s] %s(%s)\n",
> > >                                     current_timestring(talloc_tos(),
> lp_debug_hires_timestamp()), level, header_str, location, func );
> > > }
> > >
> > > current_timestring returns dynamically allocated memory which no-one frees.
> > > The patch is attached.
> > >
> > > Perhaps you are already aware of this bug and fixed it, I didn't check latest
> releases.
> >
> > Interesting. What load testing tools are you using so we
> > can see if a talloc_tos() leak is happening ? (As Volker
> > already pointed out, this really shouldn't happen with
> > normal debugs within a 'standard' main loop). Do you
> > know what specific debug you're seeing that causes it ?
> 
> This has already been fixed in a similar way for 3.6.x and
> master - but your fix certainly doesn't hurt for 3.5.x so
> I'm inclined to add it in. However I'd still like to know
> the context where talloc_tos() can leak memory in normal
> usage though, just in case there are other cases where
> we're allocating off talloc_tos() in a codepath where
> that context is left on the stack somehow.
> 
> Jeremy.