bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris by diekmann · Pull Request #4167

bpo-26228: pty.spawn hangs on FreeBSD, OS X, and Solaris by diekmann · Pull Request #4167 · python/cpython

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

Conversation

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 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 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

		# 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()

Choose a reason for hiding this comment

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

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 left a comment

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")

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?

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")

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.

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.

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.

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

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:

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

* Linux -> Unix
* More details about the behavior of spawn

Copy link

Contributor

ambv commented Aug 11, 2021

ambv added a commit to ambv/cpython that referenced this issue

Aug 13, 2021

Co-authored-by: Cornelius Diekmann <c.diekmann@googlemail.com>

Copy link

Contributor

ambv commented Aug 13, 2021

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

miss-islington added a commit to miss-islington/cpython that referenced this issue

Aug 13, 2021

…ythonGH-27754)

Co-authored-by: Cornelius Diekmann <c.diekmann@googlemail.com>
(cherry picked from commit dd8eb30)

Co-authored-by: Łukasz Langa <lukasz@langa.pl>

ambv added a commit that referenced this issue

Aug 13, 2021

Co-authored-by: Cornelius Diekmann <c.diekmann@googlemail.com>

miss-islington added a commit that referenced this issue

Aug 13, 2021

Co-authored-by: Cornelius Diekmann <c.diekmann@googlemail.com>
(cherry picked from commit dd8eb30)

Co-authored-by: Łukasz Langa <lukasz@langa.pl>