[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Changes by Ned Deily : -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bug

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ronald Oussoren added the comment: I'd be in favour of closing this issue, I haven't seen the problem in a while and it is almost certainly due to a platform bug on OSX 10.6. -- ___ Python tracker

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ned Deily added the comment: Has anyone seen this problem on other than OS X 10.6? If not, I suggest we assume it was, in fact, due to a platform bug and close. -- ___ Python tracker _

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Flávio Ribeiro added the comment: Ronald, I thought it could be an `atomic` issue by the fact that test_rename transforms a filename in tmp and then it change again to the original name. Not being atomic, the rename will not finish the executation of the first one (even though a return code

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Rafael Caricio added the comment: I had this problem when I run the tests in my machine (Mac OSX 10.6.8). The intermittence happen here. -- nosy: +rafaelcaricio ___ Python tracker

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ronald Oussoren added the comment: Whether or not rename is atomic should be irrelevant for test_rename. Test_rename "just" performs renames in a tight loop and doesn't do concurrent access from another thread. The test result seems to indicate that rename() sometimes isn't done yet when the

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ned Deily added the comment: Thanks, Flávio. That configuration looks perfectly normal and what I use so that should not be an issue. Interesting link, David. I'm not able to reproduce that failure on 10.6.8 using the procedure in the link but I am running 10.6.8 on a virtual machine so th

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Flávio Ribeiro added the comment: Hi Ned, I've used ./configure --with-pydebug && make -j2 $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. $ printenv | grep LC_ $ printenv| grep LANG LANG=en_US.UTF-8

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

R. David Murray added the comment: I found this link: http://www.weirdnet.nl/apple/rename.html in issue 8828, which sounds like it is relevant. (I thought I remembered something about rename not being atomic on OS X.) I didn't read it through, but maybe Apple fixed the bug. --

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ned Deily added the comment: And OS X doesn't support the *at system calls so HAVE_RENAMEAT will always be false on OS X. I don't recall every seeing this test fail before. -- ___ Python tracker

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Ned Deily added the comment: I haven't been able to reproduce this failure on either 10.6 or 10.7 with or without pydebug and either at 3fbfa61634de or the now slightly more current tip. What filesystem are you running the test under? What ./configure options did you use? What compiler did

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Flávio Ribeiro added the comment: For doc purposes: My first shot is that in my machine the os.rename isn't atomic and this could be generating an overhead somehow. Looking at the code, I found decisions being made on posixmodule.c about what `rename` function should be used: #ifdef HAVE_RE

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Hugo Lopes Tavares added the comment: I had no problems after running for a very long time (using -F). I am using Mac OSX 10.6.8. -- nosy: +hltbra ___ Python tracker ___ __

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Tatiana Al-Chueyr added the comment: r.david.murray: yes, MacOS X 10.6.8 we managed to reproduce this in other 2 MacBook Pro 8.1. -- ___ Python tracker ___

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

R. David Murray added the comment: Tatiana, are you on a Mac as well? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

R. David Murray added the comment: By the way, you can use -F to run the test suite until it fails: ./python -m test -F test_pep277 -- nosy: +r.david.murray ___ Python tracker __

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

Tatiana Al-Chueyr added the comment: I had the same problem here, after running several times... $ for i in {1..10}; do ./python.exe -m test test_pep277; done [1/1] test_pep277 test test_pep277 failed -- Traceback (most recent call last): File "/Users/tatiana/code/cpython/Lib/test/test_pep2

[issue15398] intermittence on UnicodeFileTests.test_rename at test_pep277 on MacOS X

New submission from Flávio Ribeiro : Found a intermittent test on UnicodeFileTests.test_rename method. Python Version: Python 3.3.0b1 Hg commit hash: 3fbfa61634de MacOS X version 10.6.8 How can be reproduced: bumblebee:~/dev/cpython[] $ for i in {1..10}; do ./python.exe -m test test_pep277;