f.write(s) for s > 2GB hangs in win64 (and win32?)

[BillSteinmetz]

BPO	9015
Nosy	@amauryfa, @vstinner

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-07-05.09:46:58.257>
created_at = <Date 2010-06-16.23:20:44.777>
labels = ['extension-modules', 'expert-IO', 'OS-windows', 'type-crash']
title = 'f.write(s) for s > 2GB hangs in win64 (and win32?)'
updated_at = <Date 2011-07-05.09:46:58.255>
user = 'https://bugs.python.org/BillSteinmetz'

bugs.python.org fields:

activity = <Date 2011-07-05.09:46:58.255>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2011-07-05.09:46:58.257>
closer = 'vstinner'
components = ['Extension Modules', 'Windows', 'IO']
creation = <Date 2010-06-16.23:20:44.777>
creator = 'Bill.Steinmetz'
dependencies = []
files = []
hgrepos = []
issue_num = 9015
keywords = []
message_count = 9.0
messages = ['107964', '107966', '120313', '120379', '120385', '120386', '120387', '125259', '139839']
nosy_count = 5.0
nosy_names = ['amaury.forgeotdarc', 'vstinner', 'cgohlke', 'Bill.Steinmetz', 'mspacek']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue9015'
versions = ['Python 2.6']

[BillSteinmetz]

Here's my Python version info:
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32

Here's my code that won't return (Start with a file > 4GB "hugefile.bin"):

siz = (1<<32)

print "making array (%d) bytes" % siz
fin = open("hugefile.bin","rb")
a = array.array("B")
a.fromfile(fin, siz)
fin.close()

print "writing array (%d) bytes" % siz
fout = open("foo.bin","wb")
a.tofile(fout)
print "wrote 2^32 bytes with array.tofile"

I never get the third print statement :(

[BillSteinmetz]

Looks like the issue is Microsoft's fwrite

[cgohlke]

This seems to be related: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/7c913001-227e-439b-bf07-54369ba07994

[mspacek]

NumPy is addressing this with a workaround in its ndarray, calling fwrite multiple times in reasonably sized chunks. See http://projects.scipy.org/numpy/ticket/1660

[mspacek]

It turns out this isn't just a problem with array.array. It's a problem with Python's file.write() as well. Here's my test code:

# file.write() test:
FOURGBMINUS = 2**32 - 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(FOURGBMINUS//len(s))])
assert len(longs) == FOURGBMINUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()

FOURGB = 2**32
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(FOURGB//len(s))])
assert len(longs) == FOURGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 0 bytes
f.close()

SIXGB = 2**32 + 2**31
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(SIXGB//len(s))])
assert len(longs) == SIXGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 2**31 bytes
f.close()

# file.read test:
TWOGB = 2**31
TWOGBPLUS = TWOGB + 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(TWOGBPLUS//len(s))])
assert len(longs) == TWOGBPLUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()
f = open('test.txt', 'r')
longs = f.read() # works, but takes >30 min, memory usage keeps jumping around
f.close()
del longs
# maybe f.read() reads 1 char at a time til it hits EOL. try this instead:
f = open('test.txt', 'r')
longs = f.read(TWOGBPLUS) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB - 1) # works, takes only seconds
f.close()

So, I guess in windows (I've only tested in 64-bit Windows 7, Python 2.6.6 amd64), file.write() should call fwrite multiple times in chunks no greater than 2**31 bytes or so. Also, calling f.read(nbytes) where nbytes >= 2**31 raises "OverflowError: long int too large to convert to int". I don't have either of these problems in 64-bit Linux (Ubuntu 10.10) on the same machine (i7, 12GB).

[mspacek]

I suppose someone should confirm this problem on Py > 2.6?

[amauryfa]

It's still an issue with 2.7, and even with 3.2a2, see bpo-9611.

[vstinner]

r87722 should fix the issue, but I didn't tested the fix... see bpo-9611 for more information.