Memory leaks in passdb.c ?

[Shlomi Yaakobovich]

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.

Here's 1 output from valgrind:

==13597== 584727 (23518 direct, 561209 indirect) bytes in 429 blocks are definitely lost in loss record 47 of 53
==13597==    at 0x1B8FE7F2: malloc (vg_replace_malloc.c:149)
==13597==    by 0x8227D15: _talloc (talloc.c:179)
==13597==    by 0x822834E: talloc_named_const (talloc.c:417)
==13597==    by 0x8229007: _talloc_memdup (talloc.c:892)
==13597==    by 0x8229061: talloc_strdup (talloc.c:910)
==13597==    by 0x822A373: talloc_sub_basic (substitute.c:511)
==13597==    by 0x81E4384: init_sam_from_buffer_v2 (passdb.c:1827)
==13597==    by 0x81E52B6: pdb_copy_sam_account (passdb.c:2224)
==13597==    by 0x826B343: copy_serverinfo (auth_util.c:927)
==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 the talloc_sub_basic function gets called as an argument of set_home_dir:

pdb_set_homedir(sampass, 
			talloc_sub_basic(sampass->mem_ctx, username, lp_logon_home()),
			PDB_DEFAULT);

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.


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

Were these errors corrected ?  Any ideas ?

Thanks
Shlomi