Skip to content

Conversation

@zdevito
Copy link
Contributor

@zdevito zdevito commented Oct 20, 2022

Stack from ghstack (oldest at bottom):

It seems like when popen.communicate() is used it waits for all the
desendents of popen to close the stdin/stderr. However, if we have
have worker processes running in the child, and the child segfaults,
those processes will stay alive until someone waitpid's the child.
Since those children have open handles to the stdin/stderr pipe,
communicate never returns.

This change just writes the output to temp files and directly calls
wait() on the child, which returns as soon as it dies.

cc @jansel @lezcano @fdrocha

It seems like when popen.communicate() is used it waits for all the
desendents of popen to close the stdin/stderr. However, if we have
have worker processes running in the child, and the child segfaults,
those processes will stay alive until someone waitpid's the child.
Since those children have open handles to the stdin/stderr pipe,
communicate never returns.

This change just writes the output to temp files and directly calls
wait() on the child, which returns as soon as it dies.

[ghstack-poisoned]
@pytorch-bot
Copy link

pytorch-bot bot commented Oct 20, 2022

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/87335

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Failures, 7 Pending

As of commit 89fda0d:

The following jobs have failed:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

zdevito added a commit that referenced this pull request Oct 20, 2022
It seems like when popen.communicate() is used it waits for all the
desendents of popen to close the stdin/stderr. However, if we have
have worker processes running in the child, and the child segfaults,
those processes will stay alive until someone waitpid's the child.
Since those children have open handles to the stdin/stderr pipe,
communicate never returns.

This change just writes the output to temp files and directly calls
wait() on the child, which returns as soon as it dies.

ghstack-source-id: 9877330
Pull Request resolved: #87335
@zdevito zdevito requested a review from anijain2305 October 20, 2022 00:04
@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Oct 20, 2022
@zdevito
Copy link
Contributor Author

zdevito commented Oct 20, 2022

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

@pytorchmergebot
Copy link
Collaborator

Merge failed

Reason: 2 additional jobs have failed, first few of them are: trunk ,trunk / linux-bionic-cuda11.7-py3.10-gcc7 / test (slow, 1, 2, linux.4xlarge.nvidia.gpu)

Details for Dev Infra team Raised by workflow job

@zdevito
Copy link
Contributor Author

zdevito commented Oct 20, 2022

@pytorchbot merge -f "unrelated failure in nvfuser"

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged immediately since you used the force (-f) flag, bypassing any CI checks (ETA: 1-5 minutes).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

@github-actions
Copy link
Contributor

Hey @zdevito.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

@facebook-github-bot facebook-github-bot deleted the gh/zdevito/197/head branch June 8, 2023 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ciflow/trunk Trigger trunk jobs on your pull request Merged module: dynamo

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants