It seems r67740 shouldn't have been committed. Since this is a severe regression, I think I'll have to revert it, and release 2.5.4 with just that change. Unless I hear otherwise, I would release Python 2.5.4 (without a release candidate) tomorrow. Regards, Martin
Martin> It seems r67740 shouldn't have been committed. Since this is a Martin> severe regression, I think I'll have to revert it, and release Martin> 2.5.4 with just that change. Martin> Unless I hear otherwise, I would release Python 2.5.4 (without a Martin> release candidate) tomorrow. I don't think there is a test case which fails with it applied and passes with it removed. If not, I think it might be worthwhile to write such a test even if it's used temporarily just to test the change. I wrote a trivial test case: Index: Lib/test/test_file.py =================================================================== --- Lib/test/test_file.py (revision 67899) +++ Lib/test/test_file.py (working copy) @@ -116,6 +116,8 @@ except: self.assertEquals(self.f.__exit__(*sys.exc_info()), None) + def testReadWhenWriting(self): + self.assertRaises(IOError, self.f.read) class OtherFileTests(unittest.TestCase): which segfaults (on Solaris 10 at least) when run with the 2.5.3 released code and which passes after I undo r67740. Should we add this to the active branches (2.6, trunk, py3k, 3.0)? Skip
On Dec 22, 2008, at 9:35 AM, skip@pobox.com wrote:
I don't think there is a test case which fails with it applied and passes with it removed. If not, I think it might be worthwhile to write such a test even if it's used temporarily just to test the change. I wrote a trivial test case:
If this is sufficient to drive a release, then whatever test there is should be part of the release as well. -Fred -- Fred Drake <fdrake at acm.org>
Martin v. Löwis wrote:
It seems r67740 shouldn't have been committed. Since this is a severe regression, I think I'll have to revert it, and release 2.5.4 with just that change.
My understanding of the problem is that clearerr() needs to be called before any FILE read operations on *some* platforms. The only platform I saw mentioned was OS X. Towards that end, I have attached a much simpler patch onto the tracker issue, which maybe somebody can verify solves the problem because I do not have access to a platform which fails the test that was originally given. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
My understanding of the problem is that clearerr() needs to be called before any FILE read operations on *some* platforms. The only platform I saw mentioned was OS X. Towards that end, I have attached a much simpler patch onto the tracker issue, which maybe somebody can verify solves the problem because I do not have access to a platform which fails the test that was originally given.
Thanks. I won't then reject the patch outright, only revert it from 2.5. I can't give this a second try, as 2.5.3 was already supposed to be the last release - I don't want to find myself reverting your patch two weeks from now. Is the approach that you add a clearerr call is added for each read operation? Regards, Martin
Martin v. Löwis wrote:
My understanding of the problem is that clearerr() needs to be called before any FILE read operations on *some* platforms. The only platform I saw mentioned was OS X. Towards that end, I have attached a much simpler patch onto the tracker issue, which maybe somebody can verify solves the problem because I do not have access to a platform which fails the test that was originally given.
Thanks. I won't then reject the patch outright, only revert it from 2.5. I can't give this a second try, as 2.5.3 was already supposed to be the last release - I don't want to find myself reverting your patch two weeks from now.
I agree, and as far as I can tell, the bug (assuming the report is accurate) only occurs on a few platforms and since it's received little attention over the life of the issue on the tracker, I imagine it's not very important to many people. And since I don't have an effected platform to test, I can't even be sure that it really solves the bug. So, I agree leave it out.
Is the approach that you add a clearerr call is added for each read operation?
Yes, I merely added clearerr() calls just prior to first the fread, fgets, and getc calls in each of the read methods for files. I'll make a clean patch against the trunk and update the issue on the tracker, then maybe the reporter or someone else with an effected platform can verify my patch. -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
participants (4)
-
"Martin v. Löwis" -
Fred Drake -
Scott Dial -
skip＠pobox.com