Fix testing #689
Fix testing #689
Conversation
|
Note that this looks like a big patch series because it's based on #681 because it needs the signalfd fixes there, but only the newest two commits are part of this series. |
test/sys/test_epoll.rs
Outdated
|
|
||
| #[test] | ||
| pub fn test_epoll_errno() { | ||
| // Create a new signalfd to use for testing. This is better than using stdin or other such fd. | ||
| let sfd = SignalFd::new(&SigSet::empty()).unwrap(); |
There was a problem hiding this comment.
is a SignalFd really the simplest kind of file descriptor that works with epoll? What about plain old files?
There was a problem hiding this comment.
Does it matter? Is signalfd overkill or would you just rather reduce cross-dependencies between tests? This seems to suggest you can use it on regular files, so let me give that a shot.
There was a problem hiding this comment.
Yes, exactly. I would rather use a plainer file descriptor type, so that this test doesn't depend on signalfd. Sockets would work too.
.travis.yml
Outdated
| @@ -97,6 +97,9 @@ matrix: | |||
| rust: beta | |||
|
|
|||
| allow_failures: | |||
| # There are too many inconsistent failures on this arch to make it Tier 1. | |||
There was a problem hiding this comment.
Frankly, I would rather just add DISABLE_TESTS=1 to powerpc. I don't think we're likely to learn much by running them, especially since we can't trust any of their failures.
There was a problem hiding this comment.
I agree, allowing failures would also make this Tier 2 not Tier 3, so good catch!
|
Well this failed with signalfd anyways...I'm wondering if this has anything to do with us removing |
|
I can reproduce the epoll test failures, but only when using the nightly compiler and only in release mode. The failure is due to unwrapping an |
|
Man, didn't even realize it was the beta that was failing and stable was passing. This passes on nightly (7-16 and 7-18) for me on x86_64-linux-gnu however. I also installed the same beta Rust version on the machine that failed and it succeeded for me. Hmmm... I'm thinking with should put the |
|
To elaborate on that, we have builds from yesterday that were still using |
|
@asomers What do you think? Should we merge it (BTW we can just merge this without bors I think). |
|
Yes, we should. I also think that you should hop in Gitter so we can talk about this Rust bug. bors r+ |
Build succeeded |
Move
powerpc-unknown-linux-gnuto Tier 2. And attempt a fix for the epoll tests that seem to fail reliably now.cc @asomers