Memory leak in cli_query_secdesc api
Brett A. Funderburg
brettf at deepfile.com
Tue Jul 22 17:31:48 GMT 2003
Greetings,
There appears to be a fairly severe memory leak in the cli_query_secdesc
api. Using the harness below with Tim's samba-python libs one can easily
verify the problem.
If you omit the query for the security descriptor, memory usage stays
constant at about 3.1MB for the python process. Otherwise, it grows by
about 400K/second.
--- BEGIN script ---
import string
from samba import smb
GENERIC_READ = 0x80000000 # per CIFS spec
credentials = {'domain': 'DOM-TEST',
'username': 'Administrator',
'password': 'admin'}
server = 'smb-test.deepfile.com'
volume = 'E$'
def leak():
list_of_filepaths = file('/tmp/filepaths.txt', 'r')
# pass exceptions to user
cnn = smb.connect(server)
cnn.session_request(server)
cnn.negprot()
cnn.session_setup(credentials)
cnn.tconx(volume)
for path in list_of_filepaths:
path = path.rstrip()
fid = None
try:
# raises RuntimeError
fid = cnn.nt_create_andx(path, GENERIC_READ)
except:
pass
else:
# Uncomment here to see leak
# sec_desc = None
# try:
# sec_desc = cnn.query_secdesc(fid)
# except:
# pass # skip and move on
#
# del sec_desc # be explicit; don't rely on GC
cnn.close(fid)
del fid # be explicit; don't rely on GC
if __name__ == "__main__":
leak()
--- END harness ---
To run the harness, first generate a list of several thousand files on a
CIFS volume to feed to the script. I mounted a volume using smbmount
then did 'find .' and piped the output through sed to come up with a
list of files in E$ formatted as such:
apache\ant\bootstrap.bat
apache\ant\bootstrap.sh
apache\ant\build.bat
apache\ant\build.sh
...
and saved the results in a file called filepath.txt
This was tested on a debian woody box with the latest CVS code in
samba_3_0. The code was built using:
./configure --prefix=/usr --sysconfdir=/etc --with-privatedir=/etc/samba
--with-lockdir=/var/state/samba --localstatedir=/var --with-python
--without-krb5
The server is a Win2K DC with all the latest service packs.
This gets into the internals of samba pretty quickly so I'll have to
leave the actual diagnosis and correction to the experts here.
Thanks,
brett
More information about the samba-technical
mailing list