Skip to content

Conversation

nodakai
Copy link
Contributor

@nodakai nodakai commented Dec 6, 2014

Reported as a part of #19120

The logic of 74fb798 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.

@nodakai
Copy link
Contributor Author

nodakai commented Dec 6, 2014

cc @alexcrichton

Sorry for the loss of precious CPU time of Buildbot!

Copy link
Member

Choose a reason for hiding this comment

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

Why are we storing all of the results? They're all just going to be Err(IoError { ... }), right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. It will do no harm anyways.
  2. This test code doesn't assume what will be returned in the Err case. Then running find_zombies() before destruction of the Err case values means a (very slightly) stricter test.

sfackler added a commit to sfackler/rust that referenced this pull request Dec 6, 2014
sfackler added a commit to sfackler/rust that referenced this pull request Dec 6, 2014
@sfackler
Copy link
Member

sfackler commented Dec 6, 2014

I ended up disabling the test to get the queue unblocked. Could you rebase this and remove the // ignore-test line?

Reported as a part of rust-lang#19120

The logic of rust-lang/rust@74fb798 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.

Also, panic! inside a loop over all children makes the logic simpler.

By not destructing the return values of Command::spawn() until
find_zombies() finishes, I believe we can conduct a slightly stricter
test.

Signed-off-by: NODA, Kai <[email protected]>
@nodakai nodakai force-pushed the libstd-fix-zombie-children-finder branch from 54deac2 to 87424c6 Compare December 6, 2014 23:09
@nodakai
Copy link
Contributor Author

nodakai commented Dec 6, 2014

@sfackler I've just pushed a rebased patch (with a small simplification of the loop logic)

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Dec 9, 2014
…inder

Reported as a part of rust-lang#19120

The logic of rust-lang/rust@74fb798 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.
@bors bors merged commit 87424c6 into rust-lang:master Dec 9, 2014
@nodakai nodakai deleted the libstd-fix-zombie-children-finder branch December 17, 2014 04:52
lnicola pushed a commit to lnicola/rust that referenced this pull request Apr 28, 2025
fix: `Extract into` function include inline variable in fmt macro
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

Successfully merging this pull request may close these issues.

4 participants