classification
Title: Erroneous zipfile test failure if the string 'bad' appears in pwd
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.5, Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: larry Nosy List: georg.brandl, ismail.badawi, larry, ned.deily, python-dev, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2014-05-18 06:46 by larry, last changed 2015-05-08 14:00 by larry. This issue is now closed.

Files
File name Uploaded Description Edit
larry.bad.zipfile.1.diff larry, 2014-06-11 11:41 review
Messages (8)
msg218735 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-05-18 06:45
If you extract current Python (3.4 or trunk) into a directory, and anywhere in the name of the directory is the string "bad", such as

/tmp/badtest
/home/baddison/src/python

then test_write_filtered_python_package() in Lib/test/test_zipfile.py will fail.  The reason is, the third subtest uses a "filterfunc" to ignore certain files, and its test to ignore files is effectively

   "bad" in fn

("fn" is an ill-conceived abbreviation for "filename")

This is overbroad.  Changing it to

   "Lib/test/bad" in fn

prevents this error.

I'm creating this issue just to remind myself to fix it.  3.4.1 is tagged and I didn't want to re-cut the release, but I didn't feel like pushing it while 3.4.1 hadn't landed in trunk yet.
msg218746 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-05-18 16:03
Here's an eye-wateringly-thorough description of the bug for the sake of posterity.

The test code in question is test_write_filtered_python_package() in Lib/test/test_zipfile.py.   This function uses PyZipFile to build a zipfile from the contents of the "Lib/test" directory.  PyZipFile scans for .py files, then compiles them into .pyc or .pyo files and adds the compiled result.

The test code actually reuses the PyZipFile object three times:

The first try succeeds, but raises some warnings because of some deliberately troublesome files in that directory that upset the compiler.  These files all contain the substring "bad" in their name, like "Lib/test/bad_coding.py".  The warnings are written to stdout; the test captures stdout and scans for the errors.  When this function is done, the zipfile contains .pyc files of all the files in Lib/test except for the ones with the substring "bad" in their name.

The second try succeeds, but ignores every file because of a "filterfunc" passed in that always returns False.  It's effectively a no-op--no files are added to the zipfile.  The test then scans the output to make sure no warnings were issued.

The third try succeeds.  It uses the "filterfunc" parameter to selectively skip the "bad" files, then scans stdout to ensure that no warnings were issued there.  However, since it's re-adding all the other files to the zipfile, this does issue a zillion UserWarning assert warnings.  The code suppresses these with a "self.assertWarns(UserWarning)" context manager.

So here's the bug.  If you untarred Python into "/tmp/goodidea", then the test works as expected.  But if you untar Python into "/tmp/badidea", then the filterfunc in the third test ignores *every* file, because *every* file contains the substring "bad".  Therefore it never adds a single file.  And therefore it never fires the UserWarning about redundantly adding a file.  Since UserWarning is never issued, and the test is supposed to issue it, the assertWarns context manager flags the test as a failure.

The easy fix: change the filterfunc to be far more selective, only filtering out paths containing the substring "Lib/test/bad".  This would still fail if you untarred Python to "/tmp/Lib/test/bad/", but hopefully nobody will do *that*.

Perhaps a still-better approach would be 
  lambda path: os.path.basename(path).startswith("bad")
msg218751 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-05-18 19:29
Testing for "Lib/test/bad" isn't correct either since the test will fail when the tests are run from an installed Python rather than just from a build directory.
msg220258 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-06-11 11:41
With this patch applied the test passes.  (Patch is against 3.4 branch.)  Look good?
msg220304 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-06-11 20:10
Yep
msg225462 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-17 19:17
The line is too long. It would be better to extract a filter as regular function. Otherwise LGTM.
msg242762 - (view) Author: Roundup Robot (python-dev) Date: 2015-05-08 13:59
New changeset bff966aed6a3 by Larry Hastings in branch '3.4':
Issue #21520: test_zipfile no longer fails if the word 'bad' appears
https://hg.python.org/cpython/rev/bff966aed6a3
msg242763 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-05-08 14:00
Checked in, with the filter function on a separate line, to 3.4. Also merged into 3.5.
History
Date User Action Args
2015-05-08 14:00:43larrysetstatus: open -> closed
resolution: fixed
messages: + msg242763

stage: commit review -> resolved
2015-05-08 13:59:34python-devsetnosy: + python-dev
messages: + msg242762
2014-08-17 19:17:34serhiy.storchakasetnosy: + serhiy.storchaka

messages: + msg225462
stage: needs patch -> commit review
2014-08-14 22:40:15ismail.badawisetnosy: + ismail.badawi
2014-06-11 20:10:01ned.deilysetmessages: + msg220304
2014-06-11 11:41:19larrysetfiles: + larry.bad.zipfile.1.diff
keywords: + patch
messages: + msg220258
2014-05-18 19:29:30ned.deilysetnosy: + ned.deily
messages: + msg218751
2014-05-18 16:03:32larrysetmessages: + msg218746
2014-05-18 07:49:39georg.brandlsetnosy: + georg.brandl
2014-05-18 06:46:00larrycreate