Issue2246

Currently ant regrtest on Windows 8.1 results in the follow errors:

     [exec] 351 tests OK.
     [exec] 14 tests skipped:
     [exec]     test__osx_support test_commands test_crypt test_curses test_dbm
     [exec]     test_lib2to3 test_pickle test_pipes test_readline test_sax
     [exec]     test_smtpnet test_subprocess test_urllib2net test_urllibnet
     [exec] 9 skips unexpected:
     [exec]     test__osx_support test_commands test_crypt test_dbm test_lib2to3
     [exec]     test_pickle test_pipes test_readline test_sax
     [exec] 17 tests failed:
     [exec]     test_bat_jy test_cmath test_dumbdbm test_import test_logging
     [exec]     test_netrc test_os_jy test_runpy test_select test_select_new
     [exec]     test_socket test_ssl test_tarfile test_tempfile test_threading
     [exec]     test_univnewlines test_zipfile
     [exec] 17 fails unexpected:
     [exec]     test_bat_jy test_cmath test_dumbdbm test_import test_logging
     [exec]     test_netrc test_os_jy test_runpy test_select test_select_new
     [exec]     test_socket test_ssl test_tarfile test_tempfile test_threading
     [exec]     test_univnewlines test_zipfile
     [exec] Result: 1

Compare this to Ubuntu 14.10, which is currently our best performing target:

     [exec] 371 tests OK.
     [exec] 14 tests skipped:
     [exec]     test__osx_support test_commands test_crypt test_curses test_dbm
     [exec]     test_lib2to3 test_pickle test_pipes test_readline test_sax
     [exec]     test_smtpnet test_subprocess test_urllib2net test_urllibnet
     [exec] 9 skips unexpected:
     [exec]     test__osx_support test_commands test_crypt test_dbm test_lib2to3
     [exec]     test_pickle test_pipes test_readline test_sax
     [exec] 2 tests failed:
     [exec]     test_cmath test_select_new
     [exec] 2 fails unexpected:
     [exec]     test_cmath test_select_new
     [exec] Result: 1

Of these failing tests on Ubuntu:

* test_select_new, which was recently added back to the regrtest is a very flaky test and needs to be addressed separately
* test_cmath is discussed in #2237

After inspection, many/most of the remaining failures between Windows and Ubuntu are likely due to the following coding pattern seen in test_tarfile:

class AppendTest(unittest.TestCase):

    def setUp(self):
        self.tarname = tmpname
        if os.path.exists(self.tarname):
            os.remove(self.tarname)

	def _add_testfile(self, fileobj=None):
        tar = tarfile.open(self.tarname, "a", fileobj=fileobj)
        tar.addfile(tarfile.TarInfo("bar"))
        tar.close()

    def _test(self, names=["bar"], fileobj=None):
        tar = tarfile.open(self.tarname, fileobj=fileobj)
        self.assertEqual(tar.getnames(), names)

    def test_non_existing(self):
        self._add_testfile()
        self._test()

test_non_existing opens, closes, opens, but doesn't then finally close self.tarname. A subsequent test then tries to close the file using os.remove, however on Windows, unlike Unix-derived systems which use a reference counting scheme (that's why os.remove = os.unlink), os.remove only works for closed files.

On CPython, this coding pattern can still work because of deterministic destruction.

One way of fixing this problem is to use test_support.gc_collect:

    def setUp(self):
	test_support.gc_collect()
        self.tarname = tmpname
        if os.path.exists(self.tarname):
            os.remove(self.tarname)

Rewriting these tests so files are properly closed is of course the preferred solution.

The other class of common failures is where sys.platform == "win32" or os.name == "nt" is being checked, generally for file system related issues. This seen in this test, along with the correction:

diff -r ea036792f304 Lib/test/test_urllib2.py
--- a/Lib/test/test_urllib2.py  Sun Jan 04 09:51:07 2015 -0700
+++ b/Lib/test/test_urllib2.py  Sun Jan 04 12:08:36 2015 -0800
@@ -29,7 +29,7 @@
             fname = os.expand(fname)
             fname = fname.translate(string.maketrans("/.", "./"))

-        if os.name == 'nt':
+        if os.name == 'nt' or (os.name == 'java' and os._name == 'nt'):
             file_url = "file:///%s" % fname
         else:
             file_url = "file://%s" % fname

Oh yeah, spare a thought for the poor Windows guy. I've fixed a good few unlink problems, but there always seem to be more. It takes a failure to reveal them.

Quite often there is a close() in the code, but because of a test failure, it is not reached. Then a bunch of subsequent tests (they all open the same file name) fail at their unlink().

Philip's suggestion here (http://sourceforge.net/p/jython/mailman/message/30237635/) is likely to be a good one, although in the same circumstances, one can usually use:

with open(...) as f:
    [suite]

Current failures:

    [exec] 18 fails unexpected:
    [exec]     test_bat_jy test_chdir test_httpservers test_import test_netrc
    [exec]     test_py_compile test_runpy test_select test_select_new test_socket
    [exec]     test_ssl test_subprocess_jy test_sys_jy test_tarfile
    [exec]     test_threading test_univnewlines test_urllib2 test_zipfile

Socket related tests are still flaky, and seem to got more so with the upgrade to Netty 4.0.25 (different timing apparently). test_chdir is mostly because of fixes for #1658, and can be easily fixed. (None of the failures in test_chdir are really interesting, it's just a question of canonical paths on Windows.) Still more work to investigate the rest.

Closing this "megabug" out. We have now broken this into a list of bugs to be fixed.