I can reproduce a memory leak in catia, smb.conf as follows:
workgroup = MYGROUP
server string = test machine
unix extensions = no
mangled names = no
path = /share1
vfs objects = catia fruit streams_xattr
writable = yes
here are the relevant lines from valgrind trace:
==104628== 64,224,360 bytes in 535,203 blocks are still reachable in loss record 547 of 547
==104628== at 0x4C29BFD: malloc (in/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==104628== by 0x5CC0ACA: __talloc_with_prefix (talloc.c:615)
==104628== by 0x5CC0C54: __talloc (talloc.c:655)
==104628== by 0x5CC1006: _talloc_named_const (talloc.c:812)
==104628== by 0x5CC3B6E: _talloc_zero (talloc.c:2219)
==104628== by 0x20036229: add_srt (vfs_catia.c:135)
==104628== by 0x20036699: init_mappings (vfs_catia.c:208)
==104628== by 0x20036734: catia_string_replace_allocate (vfs_catia.c:235)
==104628== by 0x20036A28: catia_translate_name (vfs_catia.c:318)
==104628== by 0x5413D1F: smb_vfs_call_translate_name (vfs.c:2155)
==104628== by 0x5410367: vfs_readdirname (vfs.c:811)
==104628== by 0x5389C69: ReadDirName (dir.c:1732)
issue exists on samba-4.3.6 reproduced on both FreeBSD 10.2/10.3 and Linux (Centos 7).
to reproduce the issue I simply copy 50k number of files to the samba share, then delete them. Active memory continues to grow (into GBs), never being freed until the kernel kills the smbd process. disabling the catia module results in memory usage being stable ~= 20MB.
Created attachment 11975 [details]
Can you try the attached patch? Thanks, Volker
yes this appears to resolve issue on both freebsd and linux
Created attachment 11993 [details]
Applies cleanly to 4.4, 4.3 and 4.2
Reassigning to Karolin for inclusion in 4.2, 4.3 and 4.4.
(In reply to Ralph Böhme from comment #4)
Pushed to v4-4-test, v4-3-test and v4-2-test.
Closing out bug report.