Memory leaks in passdb.c ?

Gerald (Jerry) Carter jerry at
Tue Aug 22 12:29:34 GMT 2006

Hash: SHA1

Shlomi Yaakobovich wrote:
> Hi,
> 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.

> This looks like the talloc_sub_basic function 
> gets called as an argument of set_home_dir:
> pdb_set_homedir(sampass, talloc_sub_basic(sampass->mem_ctx, ...));
> Unless pdb_set_homedir is supposed to release 
> this memory (it doesn't), it looks like a memory leak. Or
> am I missing something here ? Moreover, I've seen
> several instances of using this format (talloc_sub_*
> called as an argument), and in all of them I don't
> see how the memory is released. Is this worth
> checking ?  It does not appear to happen too much,
> perhaps it was supposed to be done just once ?  Fixing
> this does not look too hard if this is indeed
> such a trivial leak.

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().

> 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.

cheers, jerry
Samba                                    -------
Centeris                         -----------
"What man is a man who does not make the world better?"      --Balian
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list