Title: test_surrogates of test_fileio fails sometimes on OS X 10.4
Type: Stage: resolved
Components: Tests Versions: Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ned.deily Nosy List: ned.deily, python-dev
Priority: normal Keywords: buildbot, needs review, patch

Created on 2013-02-03 08:46 by ned.deily, last changed 2013-02-12 06:12 by ned.deily. This issue is now closed.

File name Uploaded Description Edit
issue17111.patch ned.deily, 2013-02-11 03:21
Messages (3)
msg181246 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-02-03 08:46
Seen on "X86 Tiger 2.7" buildbot (

test_surrogates (test.test_fileio.OtherFileTests) ... test test_fileio failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/", line 455, in test_surrogates'Bad output: %r' % out)
AssertionError: Bad output: 'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nIOError: [Errno 22] Invalid argument: \'\\xed\\xb2\\x80.txt\'\n[20282 refs]\n'

Looking into it a bit, the test attempts to open a file with a filename containing surrogates.  On OS X 10.4 (Tiger), an attempt to open such a file on a standard HFS+ file system appears to always fail with the above error 22 (EINVAL), rather than error 2 (ENOENT) "No such file or directory" as the test expects and as more recent versions of OS X do.  So the test should probably be changed to expect either error code.  I'm attaching a patch that should do that.

However, there is another issue.  The test does not always fail on 10.4 as one would expect.  The test on the buildbot sometimes succeeds.  On my own 10.4 system, while I predictably receive an EINVAL when attempting to open the file, running test_fileio in isolation seems to always pass and it's not obvious why it does.  The first part of the test, the local open fails as expected but, without the patch, the test of an open in a subprocess passes when it should be failing.  But I was able to reproduce the Error 22 failure, as seen on the buildbot failures, with the same interpreter build by using a --randseed value from one of the buildbot failures.  So there appears to be a test interaction problem here as well (environment variables?).

/python.exe -Wd -3 -E -tt  -R ./Lib/test/ -uall -rwW --randseed=2535964
msg181870 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-02-11 03:21
After writing the simplest possible test of open(2) in C to eliminate anything in Python, I finally established that the seemingly random behavior of the test is in fact caused by a rather odd bug in OS X 10.4.  The filename being used in the test is intended to be invalidly encoded.  On 10.4, open(2) of that filename returns errno 2 (ENOENT) as expected *if* the containing directory is empty.  But if there is at least one existing file in the directory, the open returns errno 22 (EINVAL) instead.  Go figure!  Knowing that, it's easy to reproduce the test failure by running the test directly.  So, the buildbot failures are intermittent depending on what files previous tests have left behind in the working directory. (I haven't checked intermediate versions but current OS X 10.8 does not have this odd behavior: ENOENT is always returned.)  The original proposed solution still seems to me to be the right one: simply change the test to pass if either EINVAL or ENOENT is returned.
msg181943 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-02-12 06:11
New changeset 9497adb7355f by Ned Deily in branch '2.7':
Issue #17111: Prevent test_surrogates (test_fileio) failure on OS X 10.4.
Date User Action Args
2013-02-12 06:12:53ned.deilysetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2013-02-12 06:11:38python-devsetnosy: + python-dev
messages: + msg181943
2013-02-11 03:23:12ned.deilysetfiles: - issue_XXXXX_test_fileio.patch
2013-02-11 03:21:17ned.deilysetfiles: + issue17111.patch
assignee: ned.deily
messages: + msg181870

stage: patch review -> commit review
2013-02-03 08:46:35ned.deilycreate