@serhiy-storchaka Do you mind reviewing this? I am not completely happy about the code to wait for the inode to be created but I don't know if I am missing something obviously better.

I am referring to this code:

        max_tries = 3
        while not os.path.exists(outfile) and max_tries:
            max_tries -= 1
            time.sleep(0.1)

Note: This code has changed in 28a8ced

There is still a race condition. It is possible that the file is created, but is still empty.

Relying on time is not reliable. The child can be paused at any moment.

If the child is paused the self.assertEqual(os.waitpid(pid, 0), (pid, 0)) will still block until the child actually finishes, right? Notice that we are waiting until the inode is created after the child has finished. Also, we are flushing now stdout before the child finishes.

Commit 1ad0a08 handles the situation in which the file is created but nothing is still written into it.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@vstinner It seems that the memory corruption is due to a bug in glibc<2.20. There is a discussion on the issue to skip the test for older versions of glibc or add a workaround.

I have made the requested changes; please review again

Thanks for making the requested changes!

@vstinner: please review the changes made to this pull request.

@zhangyangyu Done in 869dd1c

I can confirm that this PR fixes both bugs. Tested on gcc110.fsffrance.org:

[pablogsal@gcc1-power7 cpython]$ git rev-parse HEAD
2c7f50d712bb9f64c53404c2629ce1998e6e2b0f

[pablogsal@gcc1-power7 cpython]$ uname -a
Linux gcc1-power7.osuosl.org 3.10.0-514.26.2.el7.ppc64 #1 SMP Mon Jul 10 02:26:53 GMT 2017 ppc64 ppc64 ppc64 GNU/Linux

[pablogsal@gcc1-power7 cpython]$ ldd --version
ldd (GNU libc) 2.17

[pablogsal@gcc1-power7 cpython]$ ./python -m unittest test.test_posix
ss....s....................ss................ss............s...s.....................................
----------------------------------------------------------------------
Ran 101 tests in 1.684s

OK (skipped=9)

[pablogsal@gcc1-power7 cpython]$ ./python -m test test_posix -R 3:3

Run tests sequentially
0:00:00 load avg: 3.94 [1/1] test_posix
beginning 6 repetitions
123456
......

== Tests result: SUCCESS ==

1 test OK.

Total duration: 9 sec
Tests result: SUCCESS

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@serhiy-storchaka I am going to open another PR for the changes in posixmodule.c leaving this one for the tests only.

Created #7685 for the memory problems. This PR is only for the test race conditions.

I have simplified this bugfix:

As far as I understand this won't finish until the inode is created and the data is written to disk:

import sys, os
sys.stdout.write("hello")
sys.stdout.flush()
os.fsync(sys.stdout.fileno())

and on the parent waitpid blocks until the child finished with 0 (otherwise it fails the check):

self.assertEqual(os.waitpid(pid, 0), (pid, 0))

Unless I am missing something there is no race condition. When waitpid exists successfully, the file has to be there.

Let's see if the commit cb97073 fixed tests on buildbots.

PPC64 Fedora 3.x, PPC64LE Fedora 3.x, s390x Debian 3.x and s390x RHEL 3.x buildbots are back to green thanks to the commit cb97073, so I don't think that this change is still needed. I close the PR.