Spurious segfault in tests for musl

[alexcrichton]

First seen on Travis, the error looks like:

     Running build/x86_64-unknown-linux-gnu/stage2-std/x86_64-unknown-linux-musl/release/deps/coretest-a84303f8bbcf2658
running 607 tests
..........................................................................................................................................................................................................................................................................................................................ii....................................................................................................................................................................................................................................................error: process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/x86_64-unknown-linux-musl/release/deps/coretest-a84303f8bbcf2658 --quiet` (signal: 11, SIGSEGV: invalid memory reference)
To learn more, run the command again with --verbose.
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "-j" "4" "--target" "x86_64-unknown-linux-musl" "--release" "--frozen" "--manifest-path" "/checkout/src/rustc/std_shim/Cargo.toml" "--features" "panic-unwind jemalloc backtrace" "-p" "std_shim" "-p" "core" "-p" "std" "-p" "libc" "-p" "compiler_builtins" "-p" "unwind" "-p" "build_helper" "-p" "std_unicode" "-p" "rand" "-p" "alloc" "-p" "alloc_system" "-p" "collections" "-p" "panic_abort" "--" "--quiet"

cleaned up as:

error: process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/x86_64-unknown-linux-musl/release/deps/coretest-a84303f8bbcf2658 --quiet` (signal: 11, SIGSEGV: invalid memory reference)

This means that the test harness itself segfaulted. Sounds quite suspicious!

[est31]

maybe the actual failing test has nothing to do with the actual issue, but counting the dots, the test that's failing is number 560, which is test ptr::test_as_mut.

[est31]

err, that was the last one that succeeded, the one which would come next is ptr::test_as_ref

[alexcrichton]

@est31 sounds plausible! Note though that tests are run in parallel so I don't think we can know for certain which test failed, unfortunately :(

I'll also note that I tried running this locally thousands of times, but none of them segfaulted :(

[alexcrichton]

Looks like this just happened in collectionstest as well. Still musl specific.

[alexcrichton]

After running all of these test suites locally thousands of times I'm still unable to reproduce. I'm not entirely sure what's going on here..

[alexcrichton]

Debugging this a bit, I took the two most recent failures and diffed the set of tests which completed successfully from the previous successful run. The two diffs I got were:

• diff1
• diff2

I was hoping that perhaps one test was spuriously segfaulting, but that does not appear to be the case.

[alexcrichton]

Musl hasn't been updated yet, but I've heard that it's going to be fixed before the next release, although it's unclear when the next release will be.

[alexcrichton]

This hasn't shown up in quite some time now so perhaps it was indeed fixed with the last musl update!