Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)

[Jeremy Allison]

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.