test_urllibnet failing on Windows
I'm not familiar with this test. In a release build: """ C:\Code\python\PCbuild>python ../lib/test/test_urllibnet.py testURLread (__main__.URLTimeoutTest) ... ok test_bad_address (__main__.urlopenNetworkTests) ... ok test_basic (__main__.urlopenNetworkTests) ... ok test_fileno (__main__.urlopenNetworkTests) ... ERROR test_geturl (__main__.urlopenNetworkTests) ... ok test_info (__main__.urlopenNetworkTests) ... ok test_readlines (__main__.urlopenNetworkTests) ... ok test_basic (__main__.urlretrieveNetworkTests) ... ok test_header (__main__.urlretrieveNetworkTests) ... ok test_specified_path (__main__.urlretrieveNetworkTests) ... ok ====================================================================== ERROR: test_fileno (__main__.urlopenNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/test_urllibnet.py", line 91, in test_fileno FILE = os.fdopen(fd) OSError: (0, 'Error') ---------------------------------------------------------------------- Ran 10 tests in 7.081s FAILED (errors=1) Traceback (most recent call last): File "../lib/test/test_urllibnet.py", line 149, in ? test_main() File "../lib/test/test_urllibnet.py", line 146, in test_main urlretrieveNetworkTests) File "C:\Code\python\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "C:\Code\python\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "../lib/test/test_urllibnet.py", line 91, in test_fileno FILE = os.fdopen(fd) OSError: (0, 'Error') """ In a debug build: """ C:\Code\python\PCbuild>python_d ../lib/test/test_urllibnet.py testURLread (__main__.URLTimeoutTest) ... ok test_bad_address (__main__.urlopenNetworkTests) ... ok test_basic (__main__.urlopenNetworkTests) ... ok test_fileno (__main__.urlopenNetworkTests) ... """ and there it dies with an assertion error in the bowels of Microsoft's fdopen.c. That's called by Python's posix_fdopen, here: fp = fdopen(fd, mode); At this point, fd is 436. MS's fdopen is unhappy because only 32 handles actually exist at this point, and 436 is bigger than that. In the release build, the MS assert doesn't (of course) trigger; instead, that 436 >= 32 causes MS's fdopen to return NULL.
Tim> I'm not familiar with this test. Tim> In a release build: ... Brett added a bunch of tests to that file the other day. I imagine he'll take a look when the sun comes up on the west coast. Skip
I'm not familiar with this test.
Me neither, but Brett C should be. :-)
In a debug build:
""" C:\Code\python\PCbuild>python_d ../lib/test/test_urllibnet.py testURLread (__main__.URLTimeoutTest) ... ok test_bad_address (__main__.urlopenNetworkTests) ... ok test_basic (__main__.urlopenNetworkTests) ... ok test_fileno (__main__.urlopenNetworkTests) ... """
and there it dies with an assertion error in the bowels of Microsoft's fdopen.c. That's called by Python's posix_fdopen, here:
fp = fdopen(fd, mode);
At this point, fd is 436. MS's fdopen is unhappy because only 32 handles actually exist at this point, and 436 is bigger than that. In the release build, the MS assert doesn't (of course) trigger; instead, that 436 >= 32 causes MS's fdopen to return NULL.
The test assumes that the fileno() from a socket object can be passed to os.fdopen(). That works on Unix. But on Windows it cannot, the small ints used to refer to open files are chosen from a different (though potentially overlapping) space than the small ints used to refer to open sockets, and the two cannot be mixed. So the test should be disabled on Windows. I don't know if we can protect os.fdopen() from crashing when passed an out of range number. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
The test assumes that the fileno() from a socket object can be passed to os.fdopen().
Yup, Jeremy figured that out here. I have a patch waiting to go, but SF isn't cooperating.
That works on Unix. But on Windows it cannot, the small ints used to refer to open files are chosen from a different (though potentially overlapping) space than the small ints used to refer to open sockets, and the two cannot be mixed.
Just so.
So the test should be disabled on Windows.
I don't know if we can protect os.fdopen() from crashing when passed an out of range number.
This is an issue only in the MSVC debug build. The release-build MS libraries *still* explicitly check for out-of-range, and arrange for an error return when it is out of range. I really don't understand why they're asserting in-range in their debug build libraries, because nothing in *their* code assumes the fd is in-range -- their code is defensive enough in the release build that nothing bad will happen even when it is out of range.
participants (3)
-
Guido van Rossum -
Skip Montanaro -
Tim Peters