classification
Title: test_tarfile fails intermittently on Windows
Type: behavior Stage: needs patch
Components: Tests, Windows Versions: Python 3.2
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, jaraco
Priority: normal Keywords:

Created on 2010-04-05 17:24 by jaraco, last changed 2010-04-06 04:24 by brian.curtin. This issue is now closed.

Messages (5)
msg102386 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2010-04-05 17:24
Using Windows 7 32-bit, and /branches/py3k@79802.

When I run the test_tarfile from the regrtest script, often the first run will succeed and subsequent runs will fail (though sometimes a first run will fail and rarely a subsequent run will succeed). It appears to be a timing issue. The output from a failed attempt is included below.

Passing -v to the regrtest script prevents the failure from occurring. Also disabling test_extract_hardlink test prevents the failure from occurring in most cases. I found that enabling pdb and setting a trace in test_extract_hardlink prevented the error from occurring. I also attempted closing the tarfile explicitly (including in a finally block) and putting time.sleep(1) at the beginning or end of that test, but that seemed to have no effect.

I am beginning to suspect that this problem is related to an indexer or malware scanner on the system checking the file after it's created, causing it to be locked at the time it's scheduled to be deleted.

PS C:\Users\jaraco\projects\public\python-core-3.x-svn> pcbuild\python .\lib\test\regrtest.py test_tarfile
test_tarfile
test test_tarfile crashed -- <class 'WindowsError'>: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'
'test_tarfile' left behind directory '@test_5196_tmp' and it couldn't be removed: [Error 32] The process cannot access the file because it is being used by another process: '@test_5196_tmp\\testtar.tar.gz'
1 test failed:
    test_tarfile
Traceback (most recent call last):
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 400, in temp_cwd
    yield os.getcwd()
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File ".\lib\test\regrtest.py", line 687, in main
    sys.exit(len(bad) > 0 or interrupted)
SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 404, in temp_cwd
    rmtree(name)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 184, in rmtree
    shutil.rmtree(path)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 251, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 256, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 254, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'
msg102388 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-04-05 17:33
So far I've only seen this with os.symlink from #1578269 applied, but I will try more runs on a vanilla py3k to see if I can catch it.
msg102389 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2010-04-05 17:40
> To be clear, all of my tests were without any patches applied.
msg102431 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2010-04-06 03:12
I've tried reproducing this on a clean system and have thusfar been unable to. I'll try to eliminate variables on the failing system and perhaps this will elicit some information about what's causing the intermittent failures with the symlink patch.
msg102435 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2010-04-06 04:13
After grabbing a clean checkout, I'm unable to reproduce this problem where I was seeing it earlier, so I suspect the problem is in fact related to one or more lingering patches that were applied to the source. Please close this ticket as invalid.
History
Date User Action Args
2010-04-06 04:24:36brian.curtinsetresolution: not a bug
2010-04-06 04:13:12jaracosetstatus: open -> closed

messages: + msg102435
2010-04-06 03:12:41jaracosetmessages: + msg102431
2010-04-05 17:40:27jaracosetmessages: + msg102389
2010-04-05 17:33:42brian.curtinsetnosy: + brian.curtin
messages: + msg102388

components: + Windows
type: behavior
stage: needs patch
2010-04-05 17:24:19jaracocreate