[issue16606] hashlib memory leak
New submission from Thorsten Simons:
hashlib seems to leak memory when used on a Linux box (whereas the same works
fine when run under Windows 7) (tested w/ Python 3.2.1 and 3.2.3)
snip file mem.py
import hashlib
#file = 'B:\\video\\TEST\\01_file_10G'
file = '/video/TEST/01_file_10G'
myhash = hashlib.sha256()
with open(file, rb) as f:
for buffer in f:
myhash.update(buffer)
print('hash =', myhash.hexdigest())
snip
On Windows, 'python3 mem.py' occupies roundabout 7 MB memory,
on Linux (OpenSuse 12.2), it quickly acquires all available memory, then all
swap, than get's killed.
--
components: Library (Lib)
messages: 176907
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: hashlib memory leak
type: resource usage
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16606
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: forgot to say that this is about huge files (tested w/ a 10GB file) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: Antoine, this was of great help - no memory leaking anymore... So, I asume that somewhere in the iteration the read file is buffered? Does that make sense or - was it the developers intention? Thank you, Regards, Thorsten -- resolution: - works for me ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: OK, learned something again - should have known this :-( Thank you! Thorsten -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
Thorsten Simons t...@snomis.de added the comment: Gentlemen, thank you for your contribution - the information about the Samba fix solved the problem! -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13471 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
New submission from Thorsten Simons t...@snomis.de:
Using Python '3.2.2 (default, Sep 4 2011, 09:07:29) [MSC v.1500 64 bit
(AMD64)]' on Windows 7 Professional SP1:
If you set an access time for a file beyond Jan. 2038 on a file stored in a
local NTFS filesystem, all's well:
os.utime('c:\\temp_target\\ulp', (3433232323, 3433232323))
os.stat('c:\\temp_target\\ulp')
nt.stat_result(st_mode=33206, st_ino=2251799813820060, st_dev=0, st_nlink=1,
st_uid=0, st_gid=0, st_size=0, st_atime=3433232323, st_mtime=3433232323,
st_ctime=1322133855)
time.ctime(3433232323)
'Mon Oct 17 13:38:43 2078'
If you try to do this on a remote share (mounted as y:), provided by a Linux
x64 box running Samba x64, things are different:
os.utime('y:\\temp_target2\\ulp', (3433232323, 3433232323))
os.stat('y:\\temp_target2\\ulp')
nt.stat_result(st_mode=33206, st_ino=67150103, st_dev=0, st_nlink=1, st_uid=0,
st_gid=0, st_size=0, st_atime=910692730085, st_mtime=910692730085,
st_ctime=1322133629)
time.ctime(910692730085)
Traceback (most recent call last):
File pyshell#22, line 1, in module
time.ctime(910692730085)
ValueError: unconvertible time
So, setting of access/modification time does not work - assumeably, we run into
a 32-bit boundary somewhere...
Interestingly, if you set the respective access time from a Linux x64 box, you
can see the right access time within Windows 7 via Explorer/Properties...
--
components: Windows
messages: 148248
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: setting access time beyond Jan. 2038 on remote share failes on Win7 x64
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13471
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files misbehaviour ?
Thorsten Simons t...@snomis.de added the comment: Hi Éric, All, thank you for the directions you gave me! It's all about a call of os.path.basename() missing in sdist.py. Pls. see attached diff. Regards, Thorsten -- keywords: +patch Added file: http://bugs.python.org/file20546/fix-sdist.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10932 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files missbehaviour ?
New submission from Thorsten Simons t...@snomis.de: Hi ! when specifying additional files to be distributed by distutils.core.setup, documentation says that: Each file name in files is interpreted relative to the setup.py script at the top of the package source distribution. No directory information from files is used to determine the final location of the installed file; only the name of the file is used (http://docs.python.org/py3k/distutils/setupscript.html#distutils-additional-files) Well, this seems to be incorrect - I tried to specify a file from a higher level directory, which get's copies to a target based on the whole path I specified, not just the name... Pls. see attached file for details -- assignee: tarek components: Distutils files: issue.txt messages: 126459 nosy: Thorsten.Simons, eric.araujo, tarek priority: normal severity: normal status: open title: distutils.core.setup - data_files missbehaviour ? type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file20435/issue.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10932 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
