Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Race condition in tests? #7

Closed
tomspur opened this issue Jan 7, 2015 · 4 comments
Closed

Race condition in tests? #7

tomspur opened this issue Jan 7, 2015 · 4 comments

Comments

@tomspur
Copy link
Contributor

tomspur commented Jan 7, 2015

There seems to be some kind of race condition in the testsuite on both python-3.4 and python-2.7 here on Fedora 21 (it seems to occour more often in python-3.4 though).

This is the log of the tests:
self = <tests.test_spawn.PtyTestCase testMethod=test_spawn_sh>

    def test_spawn_sh(self):
        env = os.environ.copy()
        env['FOO'] = 'rebar'
        p = PtyProcess.spawn(['sh'], env=env)
        p.read()
        p.write(b'echo $FOO\n')
        time.sleep(0.1)
        response = p.read()
        assert b'rebar' in response

        p.sendeof()
        p.read()

        with self.assertRaises(EOFError):
>           p.read()
E           AssertionError: EOFError not raised

tests/test_spawn.py:21: AssertionError

What could cause these random tests? How can I help debugging it?

@tomspur
Copy link
Contributor Author

tomspur commented Jan 7, 2015

It seems to happen in about half of the time in test_spawn_sh and so far once in test_spawn_unicode_sh.

@takluyver
Copy link
Member

I would imagine that the race is between the subprocess responding to the EOF and the parent process calling read(). If the first read doesn't get everything that the subprocess wrote, then the second read will succeed. Does putting a tiny sleep after p.sendeof() improve matters? I'd like to find a better solution than adding sleeps, but it should check if my guess about the problem is correct.

@tomspur
Copy link
Contributor Author

tomspur commented Jan 8, 2015

Yes, that's indeed the case. The first read sometimes just gets exit and not the \r\n bit thereafter.

@takluyver
Copy link
Member

What about calling p.readline() there instead of p.read()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants