On Windows, test_distutils and test_peg_generator leak a temporary file: Microsoft

[vstinner]

Running test_distutils on Windows leaks a temporary file: Microsoft.

0:08:46 load avg: 7.14 [231/436/3] test_distutils failed (env changed) (49.1 sec) -- running: test_socket (59.3 sec), test_urllib2_localnet (33.2 sec)
(...)
Warning -- test_distutils leaked temporary files (1): Microsoft

The test should be run with -jN, like: python -m test -j1 test_distutils -v --fail-env-changed.

[vstinner]

Same issue with test_peg_generator:

0:15:37 load avg: 5.75 [424/436/5] test_peg_generator failed (env changed) (5 min 51 sec) -- running: test_largefile (38.2 sec), test_mmap (1 min 42 sec)
(...)
Warning -- test_peg_generator leaked temporary files (1): Microsoft

[Fidget-Spinner]

Warning -- test_distutils leaked temporary files (1): Microsoft

== Tests result: ENV CHANGED ==

1 test altered the execution environment:
    test_distutils

Total duration: 2.8 sec
Tests result: ENV CHANGED
ran 1 tests/3
exit 3
Tests failed: continuing with this subtest

Tests (1):
* distutils.tests.test_build_ext.BuildExtTestCase.test_build_ext

Bisection completed in 16 iterations and 0:00:38

[Fidget-Spinner]

I think there's a race condition somewhere, when I run the command you gave me multiple times (python_d.exe -m test.bisect_cmd -j1 test_distutils -v --fail-env-changed), I get different results:

Tests (1):
* distutils.tests.test_msvccompiler.msvccompilerTestCase.test_get_vc_env_unicode

Tests (1):
* distutils.tests.test_build_ext.ParallelBuildExtTestCase.test_build_ext

Tests (1):
* distutils.tests.test_build_ext.ParallelBuildExtTestCase.test_optional_extension

Tests (1):
* distutils.tests.test_build_ext.ParallelBuildExtTestCase.test_get_outputs

[vstinner]

I get different results:

bisect_cmd picks any test which reproduces the issue. So at least 4 tests leak a temporary file :-)

[vstinner]

I marked my issue #98168 as a duplicate of this issue.

[vstinner]

Sadly, I don't have the bandwidth to work on this issue, I just close it.

[zware]

I've had a chance to look into this, and it looks like what is actually left is an empty directory tree: Microsoft\VSApplicationInsights\vstelAIF-312cbd79-9dbb-4c48-a7da-3cc1a931cb70\ (that last part may not be the same every time).

I've searched around and found no way to disable this, but it may or may not be related to the worker being deployed on Azure. @zooba or @eryksun, if you have any suggestions for making this go away I'm open to them, but I wonder if it wouldn't be better to just ignore a directory called Microsoft in the leaked temporary files check.

[zware]

Hmm. It turns out that an update to VS (and an attempt to trim down the installed components) seems like it may have resolved this; the latest build (which was a rebuild of the previous failure) passed.