Memory leaks in passdb.c ?

[Shlomi Yaakobovich]

Hi Jerry,

> > We've been running vlagrind with some load over 
> > our samba 3.0.20. The test ran over night. Although
> > it's an older version, I think these findings may
> > still be valid.
> 
> There were a lot of changes in this area in 3.0.23.
> You might want to double check that this code still exists.

I looked it up, the code is still the same there.

> I'd call that sloppy programming but the substituted string
> is allocated from the sampass TALLOC_CTX, it will be freed
> when the sampass structure is dropped by TALLOC_FREE().

I see what you mean. This appears to be the case here, and I notice that the TALLOC_FREE was added in revision 15589 (May 13, 2006), which is newer than the version I'm using. I will take the new code from there and verify it solves this leak.

> > Another report from valgrind:
> > 
> > ==13597== 530006 (39916 direct, 490090 indirect) bytes in 
> 587 blocks are definitely lost in loss record 50 of 53
> > ==13597==    at 0x1B8FE7F2: malloc (vg_replace_malloc.c:149)
> > ==13597==    by 0x826AB7C: make_server_info (auth_util.c:723)
> > ==13597==    by 0x826B262: copy_serverinfo (auth_util.c:911)
> > ==13597==    by 0x826B3C7: make_server_info_guest (auth_util.c:946)
> > ==13597==    by 0x8268E15: check_guest_security (auth_builtin.c:46)
> > ==13597==    by 0x82636A6: check_ntlm_password (auth.c:255)
> > ==13597==    by 0x80BE877: check_guest_password (sesssetup.c:126)
> > ==13597==    by 0x80C0C09: reply_sesssetup_and_X (sesssetup.c:951)
> > ==13597==    by 0x80EF8F4: switch_message (process.c:1000)
> > ==13597==    by 0x80EF9AB: construct_reply (process.c:1030)
> > ==13597==    by 0x80EFEDD: process_smb (process.c:1154)
> > ==13597==    by 0x80F1141: smbd_process (process.c:1734)
> > ==13597==    by 0x82AF99E: main (server.c:1032)
> > 
> > This looks like a similar flow. This is a bit different though.
> > Both occurances appear to originate from a new session being 
> > set up. We use "security = share".
> 
> This is not technically a leak since the guest structure is set
> up once rather than having rebuild it every time we need it.
> It's never freed before exit, but is always available while
> smbd is running.

I know, but still I see the memory growing very slowly. If I would leave running for 2 days then this would grow some more. 
I was thinking that perhaps this is caused due to consecutive calls for a session setup. Perhaps it was once true that the guest structure is built once, but maybe more recent versions of Windows resend these packets some times ?  I did not see it in tcpdump though, but I found a hint in a comment before setup_new_vc_session:

/****************************************************************************
 On new VC == 0, shutdown *all* old connections and users.
 It seems that only NT4.x does this. At W2K and above (XP etc.).
 a new session setup with VC==0 is ignored.
****************************************************************************/

I will try running with tcpdump for a very long time, and perhaps catch these packets.

Shlomi