Samba 3.5.8 leaks memory in DEBUG (dbghdrclass)

[Volker Lendecke]

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