Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #11277: Remove useless test from test_zlib.
Can you clarify (preferably in the commit message as well) exactly
*why* these largefile tests are useless? For example, is there
another test that covers this already?
-jJ
On 5/7/11, nadeem.vawda
http://hg.python.org/cpython/rev/201dcfc56e86 changeset: 69886:201dcfc56e86 branch: 2.7 parent: 69881:a0147a1f1776 user: Nadeem Vawda
date: Sat May 07 11:28:03 2011 +0200 summary: Issue #11277: Remove useless test from test_zlib. files: Lib/test/test_zlib.py | 42 ------------------------------- 1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py --- a/Lib/test/test_zlib.py +++ b/Lib/test/test_zlib.py @@ -72,47 +72,6 @@ zlib.crc32('spam', (2**31)))
-# Issue #11277 - check that inputs of 2 GB (or 1 GB on 32 bits system) are -# handled correctly. Be aware of issues #1202. We cannot test a buffer of 4 GB -# or more (#8650, #8651 and #10276), because the zlib stores the buffer size -# into an int. -class ChecksumBigBufferTestCase(unittest.TestCase): - if sys.maxsize > _4G: - # (64 bits system) crc32() and adler32() stores the buffer size into an - # int, the maximum filesize is INT_MAX (0x7FFFFFFF) - filesize = 0x7FFFFFFF - else: - # (32 bits system) On a 32 bits OS, a process cannot usually address - # more than 2 GB, so test only 1 GB - filesize = _1G - - @unittest.skipUnless(mmap, "mmap() is not available.") - def test_big_buffer(self): - if sys.platform[:3] == 'win' or sys.platform == 'darwin': - requires('largefile', - 'test requires %s bytes and a long time to run' % - str(self.filesize)) - try: - with open(TESTFN, "wb+") as f: - f.seek(self.filesize-4) - f.write("asdf") - f.flush() - m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) - try: - if sys.maxsize > _4G: - self.assertEqual(zlib.crc32(m), 0x709418e7) - self.assertEqual(zlib.adler32(m), -2072837729) - else: - self.assertEqual(zlib.crc32(m), 722071057) - self.assertEqual(zlib.adler32(m), -1002962529) - finally: - m.close() - except (IOError, OverflowError): - raise unittest.SkipTest("filesystem doesn't have largefile support") - finally: - unlink(TESTFN) - - class ExceptionTestCase(unittest.TestCase): # make sure we generate some expected errors def test_badlevel(self): @@ -595,7 +554,6 @@ def test_main(): run_unittest( ChecksumTestCase, - ChecksumBigBufferTestCase, ExceptionTestCase, CompressTestCase, CompressObjectTestCase
-- Repository URL: http://hg.python.org/cpython
On Mon, May 9, 2011 at 2:53 PM, Jim Jewett
Can you clarify (preferably in the commit message as well) exactly *why* these largefile tests are useless? For example, is there another test that covers this already?
Ah, sorry about that. It was discussed on the tracker issue, but I guess I can't expect people to read through 90+ messages to figure it out :P The short version is that it was supposed to test 4GB+ inputs, but in 2.7, the functions being tested don't accept inputs that large. The details: The test was originally intended to catch the case where crc32() or adler32() would get a buffer of >=4GB, and then silently truncate the buffer size and produce an incorrect result (issue10276). It had been written for 3.x, and then backported to 2.7. However, in 2.7, zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, so passing in a buffer of >=2GB raises an OverflowError (see issue8651). This means that it is impossible to trigger the bug in question on 2.7, making the test pointless. Of course, the code that was deleted tests with an input sized 2GB-1 or 1GB, rather than 4GB (the size used in 3.x). When the test was backported, the size of the input was reduced, to avoid triggering an OverflowException. At the time, no-one realized that this also would not trigger the bug being tested for; it only came to light when the test started crashing for unrelated reasons (issue11277). Cheers, Nadeem
participants (2)
-
Jim Jewett
-
Nadeem Vawda