Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Stage 2 test failure on master branch; windows linux subsystem #49367

Closed
Phlosioneer opened this issue Mar 25, 2018 · 7 comments
Closed

Stage 2 test failure on master branch; windows linux subsystem #49367

Phlosioneer opened this issue Mar 25, 2018 · 7 comments

Comments

@Phlosioneer
Copy link
Contributor 

unix_sub@DevWindows ~/r/rust> ./x.py test src/libstd --test-args double_bind
Updating only changed submodules
Submodules updated in 0.36 seconds
    Finished dev [unoptimized] target(s) in 0.0 secs
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divdc3.c:21:1: warning: conflicting types for built-in function ‘__divdc3’ [enabled by default]
warning:  __divdc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divsc3.c:21:1: warning: conflicting types for built-in function ‘__divsc3’ [enabled by default]
warning:  __divsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divxc3.c:22:1: warning: conflicting types for built-in function ‘__divxc3’ [enabled by default]
warning:  __divxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/muldc3.c:21:1: warning: conflicting types for built-in function ‘__muldc3’ [enabled by default]
warning:  __muldc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function ‘__mulsc3’ [enabled by default]
warning:  __mulsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulxc3.c:23:1: warning: conflicting types for built-in function ‘__mulxc3’ [enabled by default]
warning:  __mulxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
    Finished release [optimized] target(s) in 0.2 secs
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.0 secs
Copying stage0 test from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.11 secs
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 codegen artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu, llvm)
    Finished release [optimized] target(s) in 0.1 secs
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divdc3.c:21:1: warning: conflicting types for built-in function ‘__divdc3’ [enabled by default]
warning:  __divdc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divsc3.c:21:1: warning: conflicting types for built-in function ‘__divsc3’ [enabled by default]
warning:  __divsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divxc3.c:22:1: warning: conflicting types for built-in function ‘__divxc3’ [enabled by default]
warning:  __divxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/muldc3.c:21:1: warning: conflicting types for built-in function ‘__muldc3’ [enabled by default]
warning:  __muldc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function ‘__mulsc3’ [enabled by default]
warning:  __mulsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulxc3.c:23:1: warning: conflicting types for built-in function ‘__mulxc3’ [enabled by default]
warning:  __mulxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
    Finished release [optimized] target(s) in 0.2 secs
Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.1 secs
Copying stage1 test from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.2 secs
Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 codegen artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu, llvm)
    Finished release [optimized] target(s) in 0.1 secs
Assembling stage2 compiler (x86_64-unknown-linux-gnu)
Uplifting stage1 std (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Copying stage2 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Uplifting stage1 test (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Copying stage2 test from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Uplifting stage1 rustc (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Copying stage2 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building rustdoc for stage2 (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.1 secs
Testing std stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divdc3.c:21:1: warning: conflicting types for built-in function ‘__divdc3’ [enabled by default]
warning:  __divdc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divsc3.c:21:1: warning: conflicting types for built-in function ‘__divsc3’ [enabled by default]
warning:  __divsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/divxc3.c:22:1: warning: conflicting types for built-in function ‘__divxc3’ [enabled by default]
warning:  __divxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/muldc3.c:21:1: warning: conflicting types for built-in function ‘__muldc3’ [enabled by default]
warning:  __muldc3(double __a, double __b, double __c, double __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function ‘__mulsc3’ [enabled by default]
warning:  __mulsc3(float __a, float __b, float __c, float __d)
warning:  ^
warning: ../../libcompiler_builtins/compiler-rt/lib/builtins/mulxc3.c:23:1: warning: conflicting types for built-in function ‘__mulxc3’ [enabled by default]
warning:  __mulxc3(long double __a, long double __b, long double __c, long double __d)
warning:  ^
    Finished release [optimized] target(s) in 0.3 secs
     Running build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/std-879e2a6b0cfef1d1

running 1 test
thread '<unnamed>' panicked at 'explicit panic', libstd/net/tcp.rs:1199:27
note: Run with `RUST_BACKTRACE=1` for a backtrace.
test net::tcp::tests::double_bind ... FAILED

failures:

failures:
    net::tcp::tests::double_bind

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 769 filtered out

error: test failed, to rerun pass '--lib'


command did not execute successfully: "/home/unix_sub/rust/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/home/unix_sub/rust/rust/src/libstd/Cargo.toml" "-p" "std" "--" "double_bind"
expected success, got: exit code: 101


failed to run: /home/unix_sub/rust/rust/build/bootstrap/debug/bootstrap test src/libstd --test-args double_bind
Build completed unsuccessfully in 0:00:18

I've never had issues doing a full compile and test of rust before. The windows linux subsystem should be equivalent to ubuntu for most intents and purposes, as far as I know.

Here's my version:

unix_sub@DevWindows ~/r/rust> uname -a
Linux DevWindows 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux

This technically isn't on master branch; but the only difference between master and my current working branch is a few ignored tests (#49366 ):

commit 559b57bf6449d1872d797ebe04a97024b0c999b2
Author: Phlosioneer <[email protected]>
Date:   Sun Mar 25 17:06:38 2018 -0400

    Ignore proc macro stage 1 tests

    A few tests related to proc-macros fail when performing stage-1
    testing. This PR adds // ignore-stage1 to them, along with a FIXME.

    Original issue: #49352

    This should (hopefully) be fixed when #49219 is merged.

commit 77e2bcb613c58ed2aeb86fdb07f470440f94f205
Merge: f5631d9 4eff4d9
Author: bors <[email protected]>
Date:   Sun Mar 25 00:02:48 2018 +0000

    Auto merge of #49141 - gnzlbg:simd_select, r=alexcrichton

    adds simd_select intrinsic

    The select SIMD intrinsic is used to select elements from two SIMD vectors using a mask:

    ```rust
    let mask = b8x4::new(true, false, false, true);
    let a = f32x4::new(1., 2., 3., 4.);
    let b = f32x4::new(5., 6., 7., 8.);
    assert_eq!(simd_select(mask, a, b), f32x4::new(1., 6., 7., 4.));
    ```

    The number of lanes between the mask and the vectors must match, but the vector width of the mask do

    Note: this intrinsic will be exposed via `std::simd`'s vector masks - users are not expected to use

commit f5631d9ac7745dd6eaea2bc6c236d5f8e54e9a18
Merge: b4aa80d 297a6e5
Author: bors <[email protected]>
Date:   Sat Mar 24 18:58:12 2018 +0000

    Auto merge of #49337 - kennytm:rollup, r=kennytm

    Rollup of 21 pull requests

    - Successful merges: #49046, #49076, #49089, #49120, #49121, #49122, #49162, #49193, #49194, #49203,
unix_sub@DevWindows ~/r/rust> git status
On branch 49352-proc-macro-test-failure
nothing to commit, working directory clean
@Phlosioneer
Copy link
Contributor Author

Can confirm that this still happens on master branch as-is, and with the newest commits.

@cuviper
Copy link
Member

cuviper commented Mar 26, 2018

The windows linux subsystem should be equivalent to ubuntu for most intents and purposes, as far as I know.

In theory, sure, but it's quite possible that Microsoft has not matched Linux behavior here.

@Phlosioneer
Copy link
Contributor Author

I'm just going to close this, then. I wanted to make sure that it was just me, and not a known issue or something.

@cuviper
Copy link
Member

cuviper commented Mar 26, 2018

FWIW, I wasn't trying to be dismissive -- just pointing out the possibility that the bug could be elsewhere. But anyway, I extracted that test to try it more easily:
https://play.rust-lang.org/?gist=4e595640c43d9dd52d3590cd34f26ebc&version=stable

This succeeds on the playground and on Fedora (4.15.10-300.fc27.x86_64), but fails on WSL+Debian (4.4.0-43-Microsoft). Maybe you could report it to https://github.com/Microsoft/WSL?

@Phlosioneer
Copy link
Contributor Author

Thanks for the reply, but I didn't intend for this to be treated as a long-living issue.

@ssomers
Copy link
Contributor

ssomers commented Dec 22, 2018 •
edited
Loading

I'm new to Rust, but I'm getting the impression that Rust is to blame here. When I further simplify cuviper's code on playground, it's finally clear to me that the test case asserts that:

  1. the system doesn't support double binding to TCP ports (the explicit panic reported here)
  2. if the system doesn't support double binding, it reports an attempt to double bind in a decent way

Why the first point? I don't know anything about multiple binding, but I'm open to the idea. On WSL, the test code reports two different file descriptors and I assume (probably will test later) that both will get the same data that gets sent to the port. Any particular reason why Rust wouldn't like that?

@ssomers
Copy link
Contributor

ssomers commented Feb 5, 2019 •
edited
Loading

On closer inspection, there are reasons to like and dislike multiple binding (as illustrated in the introduction of SO_REUSEPORT). The reason multiple binding succeeds here is because TcpListener.bind in libstd/sys_common/net.rs sets the SO_REUSEADDR socket option. What this is supposed to do, you can have your pick:

  • The comment in the Rust code says "to quickly rebind a socket, without needing to wait for the OS to clean up the previous one"
  • The author of SO_REUSEPORT in Linux suggests that SO_REUSEADDR allows freely sharing (and hijacking) the port for UDP (so not TCP)
  • The udp_bind implementation of lwIP seems to do the same as SO_REUSEPORT does, for UDP only
  • Plenty of choice on stackoverflow
  • Windows documentation on the matter suggest a lot more sharing and the behavior exhibited by the test here.

Probably for the latter, SO_REUSEADDR is not applied on Windows through if !cfg!(windows). But WSL is not Windows: in my WSL environment, rustc --print cfg lists:

target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_os="linux"
target_pointer_width="64"
target_vendor="unknown"

I see no way to tune the if !cfg!(windows) to cover WSL as well.

@ssomers ssomers mentioned this issue Feb 17, 2019
Merged
kennytm added a commit to kennytm/rust that referenced this issue Feb 18, 2019
@kennytm
Rollup merge of rust-lang#58551 - ssomers:master, r=oli-obk
b79f718 
Explain a panic in test case net::tcp::tests::double_bind

Those who try to build libstd on the Windows Subsystem for Linux experience a single failing test, where the point of failure is an explicit but anonymous panic, as reported in rust-lang#49367
This commit somewhat explains why and allows diagnosing a little.
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Feb 18, 2019
@Mark-Simulacrum
Rollup merge of rust-lang#58551 - ssomers:master, r=oli-obk
4b1eff8 
Explain a panic in test case net::tcp::tests::double_bind

Those who try to build libstd on the Windows Subsystem for Linux experience a single failing test, where the point of failure is an explicit but anonymous panic, as reported in rust-lang#49367
This commit somewhat explains why and allows diagnosing a little.
kennytm added a commit to kennytm/rust that referenced this issue Feb 20, 2019
@kennytm
Rollup merge of rust-lang#58551 - ssomers:master, r=oli-obk
ef0aadd 
Explain a panic in test case net::tcp::tests::double_bind

Those who try to build libstd on the Windows Subsystem for Linux experience a single failing test, where the point of failure is an explicit but anonymous panic, as reported in rust-lang#49367
This commit somewhat explains why and allows diagnosing a little.
@Walther Walther mentioned this issue May 25, 2020
Closed
spikespaz pushed a commit to spikespaz/dotwalk-rs that referenced this issue Aug 29, 2024
@kennytm
Rollup merge of #58551 - ssomers:master, r=oli-obk
c77f373 
Explain a panic in test case net::tcp::tests::double_bind

Those who try to build libstd on the Windows Subsystem for Linux experience a single failing test, where the point of failure is an explicit but anonymous panic, as reported in rust-lang/rust#49367
This commit somewhat explains why and allows diagnosing a little.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cuviper @Phlosioneer @ssomers