Skip to content

bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris #4167

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

Closed
wants to merge 7 commits into from

Conversation

diekmann
Copy link
Contributor

@diekmann diekmann commented Oct 29, 2017

issue26228 as github PR.

This PR contains:

  • original patch of issue26228 by Chris
  • Update of docs
  • Update of pty test suite

According to the bpo discussion, this fixes pty.spawn() on FreeBSD, OS X, and Solaris.

https://bugs.python.org/issue26228

@diekmann diekmann changed the title Bpo 26228: pty.spawn hangs on FreeBSD, OS X, and Solaris Bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris Oct 29, 2017
@diekmann diekmann changed the title Bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris Oct 29, 2017
Lib/pty.py Outdated
# If we wanted to be really clever, we would use
# the same method as subprocess() to pass the error
# back to the parent. For now just dump stack trace.
traceback.print_exc()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing module again. In PR #2932 you fixed this line. See https://bugs.python.org/review/29070/diff/19699/Lib/pty.py#newcode170.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this ... again 🎃 👻

Thank you so much for your feedback! 🥇

Copy link
Member

@vadmium vadmium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can’t see anything seriously wrong with 005dc23, although I think it would be better to test the API (pty.spawn), without depending on the internals (_copy, select, etc) if possible.

return rfds_result, [], []

def test__mock_stdin_stdout(self):
self.assertGreater(pty.STDIN_FILENO, 2, "replaced by our mock")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the method called stdin_stdout, while the body only looks at STDIN_FILENO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the following commit: A docstring explains the name and the method also checks for STDOUT_FILENO.

# called with three empty lists as file descriptors to wait
# on. Behavior of real select is platform-dependent and
# likely infinite blocking on Linux.
raise self.fail("mock select on no waitables")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect the raise statement never executes because TestCase.fail raises its own exception.

Copy link
Contributor Author

@diekmann diekmann Dec 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your suspicion is appropriate. Fixed in the following commit.


# Test that STDIN was not touched. This test simulated the
# scenario where the child process immediately closed its end of
# the pipe. This means, nothing should be copied.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the point of this test? I don’t think it matters.

You seem to be modelling a situation where input (or EOF) to the child becomes available at about the same instant that the slave terminal is closed. If _copy were written differently, it might copy the input to the child (STDIN_FILENO) before checking the pseudoterminal master (master_fd), and the test would fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, this part of the test is overly fitted for an unnecessary implementation detail. Removed in the following commit

@diekmann
Copy link
Contributor Author

diekmann commented Dec 2, 2017

Yes, blackbox tests for the API (pty.spawn) would be nice. But at the moment, they could not be merged in isolation because they would fail on FreeBSD.
My idea:

  1. This pull request contains the minimum necessary changes to the existing tests, code, and doc to fix pty.spawn.
  2. Afterwards, in isolated (and hence easier to review) pull requests, more API tests for pty.spawn may follow. The test suite in bpo-29070: Integration tests for pty module with patch from bpo-26228 #2932 already has some. But bpo-29070: Integration tests for pty module with patch from bpo-26228 #2932 is just too huge to review and has too many unrelated changes.

@ambv
Copy link
Contributor

ambv commented Aug 11, 2021

Closing in favor of GH-12049.

@ambv ambv closed this Aug 11, 2021
ambv added a commit to ambv/cpython that referenced this pull request Aug 13, 2021
@ambv
Copy link
Contributor

ambv commented Aug 13, 2021

The doc part of this was included in GH-27754.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Aug 13, 2021
…ythonGH-27754)

Co-authored-by: Cornelius Diekmann <[email protected]>
(cherry picked from commit dd8eb30)

Co-authored-by: Łukasz Langa <[email protected]>
ambv added a commit that referenced this pull request Aug 13, 2021
miss-islington added a commit that referenced this pull request Aug 13, 2021
Co-authored-by: Cornelius Diekmann <[email protected]>
(cherry picked from commit dd8eb30)

Co-authored-by: Łukasz Langa <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants