<div dir="auto">That does sound strange. How easily can you reproduce it? That majorly effects how I would try to debug something like this...<div dir="auto"><br></div><div dir="auto">If you're able to get an strace of a failed run then that would probably tell us a *lot*.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019, 16:28 Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I'm trying to track down the cause of the failed Linux tests on this <br>
build (it's also been happening on random PR builds for the last day or <br>
two, but this is the first I've seen it happen on already merged code):<br>
<br>
<a href="https://dev.azure.com/Python/cpython/_build/results?buildId=40189" rel="noreferrer noreferrer" target="_blank">https://dev.azure.com/Python/cpython/_build/results?buildId=40189</a><br>
<br>
One of the failed tests is this one from test_tarfile.py (and I think <br>
this is representative of the others):<br>
<br>
def test_file_mode(self):<br>
     # Test for issue #8464: Create files with correct<br>
     # permissions.<br>
     if os.path.exists(tmpname):<br>
         support.unlink(tmpname)<br>
<br>
     original_umask = os.umask(0o022)<br>
     try:<br>
         tar = tarfile.open(tmpname, self.mode)<br>
         tar.close()<br>
         mode = os.stat(tmpname).st_mode & 0o777<br>
         self.assertEqual(mode, 0o644, "wrong file permissions")<br>
     finally:<br>
         os.umask(original_umask)<br>
<br>
It's failing because the mode of the new TAR file is 0o666 rather than <br>
0o644. I'd guess that this means the umask() call is not having effect? <br>
But honestly this is beyond me - I don't have any idea what would cause <br>
Python to ignore that, and I don't see anything in the commit history <br>
that could be at fault.<br>
<br>
I'm hoping someone can tell me that it's definitely a platform <br>
configuration issue or it's definitely interference between two of our <br>
tests (which run in random order, which would explain the intermittent <br>
nature of this, but I haven't spotted any tests that seem likely either).<br>
<br>
To see the other failed PR builds, the full list is at <br>
<a href="https://dev.azure.com/Python/cpython/_build?definitionId=9" rel="noreferrer noreferrer" target="_blank">https://dev.azure.com/Python/cpython/_build?definitionId=9</a> and most of <br>
the ones from today have failed because of whatever is causing it.<br>
<br>
Any help?<br>
<br>
Thanks,<br>
Steve<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank" rel="noreferrer">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/njs%40pobox.com" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/njs%40pobox.com</a><br>
</blockquote></div>