Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)

[Dina_Fine at Dell.com]

Oh.. I see what you mean.
Then yes, the bug will occur only in our version of samba. Due to the additional forked process (described in the previous mail) which doesn't talloc and free the frame.
I will fix the while(1) loop of the forked processes to do the same.

Thanks for the help!
Dina Fine


> -----Original Message-----
> From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
> Sent: 30 November, 2011 15:45
> To: Fine, Dina
> Cc: samba-technical at lists.samba.org
> Subject: Re: Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)
> 
> On Wed, Nov 30, 2011 at 01:12:21PM +0000, Dina_Fine at Dell.com wrote:
> > 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.
> 
> talloc_tos() as a parent context should be freed at least
> after every SMB request is finished. The idea of
> talloc_tos() is that it is a temporary talloc context that
> is freed very soon after the routine in which it is used is
> left. This has worked well for us so far. Maybe you are
> seeing a message that is printed outside of our cental event
> loop? In master, this loop looks like
> 
>         while (True) {
>                 NTSTATUS status;
> 
>                 frame = talloc_stackframe_pool(8192);
> 
>                 errno = 0;
> 
>                 status = smbd_server_connection_loop_once(ev_ctx, sconn);
>                 if (!NT_STATUS_EQUAL(status, NT_STATUS_RETRY) &&
>                     !NT_STATUS_IS_OK(status)) {
>                         DEBUG(3, ("smbd_server_connection_loop_once failed: %s,"
>                                   " exiting\n", nt_errstr(status)));
>                         break;
>                 }
> 
>                 TALLOC_FREE(frame);
>         }
> 
> where the TALLOC_FREE(frame) should have cleaned up
> everything. Hmm. Maybe some DEBUG in a destructor called
> from within that TALLOC_FREE? Not sure how that would
> behave.
> 
> Can you please post the output of
> 
> smbcontrol <smbd-pid> pool-usage
> 
> for such a large smbd? Maybe we can nail down which exact
> stacktrace is leaking memory.
> 
> Thanks,
> 
> Volker
> 
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de