Nightly: thread '<unnamed>' panicked at 'couldn't compile the test', src/librustdoc/test.rs:326:13

[sstangl]

Our Rocket-based code is failing since this morning (2018-12-15). It's using the Nightly rust Docker image as a base.

The backtrace is available here: https://gitlab.com/openpowerlifting/opl-data/-/jobs/135130101

It seems to be failing in a doctest. The code wasn't changed recently; the change is likely in rustc since yesterday or the day before that.

To reproduce, you should be able to git clone https://gitlab.com/openpowerlifting/opl-data.git and then cd modules/opltypes and cargo test.

---- src/event.rs - event::Event::sd (line 67) stdout ----
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.0.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.1.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.10.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.11.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.12.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.13.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.14.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.2.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.3.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.4.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.5.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.6.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.7.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.8.rcgu.o" "/tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.9.rcgu.o" "-o" "/tmp/rustdoctestvHfhvp/rust_out" "/tmp/rustdoctestvHfhvp/rust_out.33dyzt1ekirinwy8.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/builds/openpowerlifting/opl-data/target/debug/deps" "-L" "/builds/openpowerlifting/opl-data/target/debug/build/backtrace-sys-ab9883be4cf29b13/out" "-L" "/builds/openpowerlifting/opl-data/target/debug/build/ring-3ef0e65adf8c5eff/out" "-L" "/builds/openpowerlifting/opl-data/target/debug/deps" "-L" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/builds/openpowerlifting/opl-data/target/debug/deps/libopltypes-4a9187ba4ef56f30.rlib" "/builds/openpowerlifting/opl-data/target/debug/deps/libstrum-d22f46e956b7b8a9.rlib" "/builds/openpowerlifting/opl-data/target/debug/deps/libserde-9db5e99214d56f64.rlib" "-Wl,--start-group" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-635e0ff12adf0a0e.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-6e856946e5dde60c.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-5db8f2a07b5e4a3f.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-67bc42cf8da35f06.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f6364059e4ec22fe.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-52c0b8a76b5c5e7d.rlib" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-34032f5d0b4c1746.rlib" "-Wl,--end-group" "/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-2df59bcd1656c57e.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /tmp/rustdoctestvHfhvp/rust_out.rust_out.7rcbfp3g-cgu.9.rcgu.o: In function `std::panicking::begin_panic':
          rust_out.7rcbfp3g-cgu.9:(.text._ZN3std9panicking11begin_panic17h5b12128523b7d438E+0x40): undefined reference to `std::panicking::rust_panic_with_hook'
          collect2: error: ld returned 1 exit status
          

thread '<unnamed>' panicked at 'couldn't compile the test', src/librustdoc/test.rs:326:13

[ghost]

I'm witnessing very similar linking errors in doctests of crossbeam-channel:

https://travis-ci.org/crossbeam-rs/crossbeam/jobs/468644578#L1083

[Centril]

cc @nagisa

[nagisa]

There are quite a few rollups in the regression-range that it is hard see which one exactly could be to blame.

[nagisa]

Observations:

• Crossbeam does not reproduce with cargo test --doc but reproduces with cargo test --doc -- --test-threads=1;
  • bisect shows a regression in libtest: Use deterministic HashMap, avoid spawning thread if there is no concurrency #56243...
• Cannot reproduce opl-data bug with either --test-threads=1 or without it.
  • Perhaps a request for a minimized test case would be warranted…

[pnkfelix]

T-compiler triage: P-high

[pnkfelix]

triage: assigning to @nagisa

[nagisa]

@stjepang can you confirm that crossbeam-rs/crossbeam#268 fixes the issue in crossbeam?

[ghost]

@nagisa Unfortunately, it doesn't.

That PR only affects crossbeam-skiplist, not crossbeam-channel (whose doctests are failing).

[nagisa]

I would like an issue for crossbeam to be filled separately. It appears that at least from the reproducibility standpoint these two issues are different and I wouldn’t want for the crossbeam issue to get lost in case we end up closing this ticket as “cannot reproduce and author has never responded”.

[ghost]

@nagisa It seems the issue in crossbeam has resolved itself with a nightly update a few weeks ago.

[nikomatsakis]

Discussed in the @rust-lang/compiler meeting. Some notes:

• We'd like to separate out the crossbeam issue, which seems separate (and maybe fixed, @nagisa wants to confirm).
• @sstangl -- are you still having a problem? are you able to produce a smaller test case at all? @nagisa was unable to reproduce.

[nagisa]

Hey @sstangl, could you try seeing if the issue has also fixed itself on your project as well? If it hasn’t, then we would love a more thorough list of reproduction steps and/or description of environment in which the issue could be reproduced.

[sstangl]

@nagisa It seems to have been fixed in our project also, and hasn't reproduced for a while.

[nagisa]

Okay, I have confirmed that indeed the crossbeam issue is fixed in the most recent nightly and is not reproducible in beta, although I could not bisect what exactly fixed this because of lacking tooling support for inverted statuses.

[nagisa]

This has been fixed by 01c6ea2.