tarpaulin: Tarpaulin v0.17.0 sometimes errors with a message about a segfault when trying to build against musl

Steps to reproduce

I’ve managed to work my code down to this minimal example:

(Clarification edit: As the title indicates, I have only encountered this when trying to build/test against musl libc; the same programs build fine when targetting glibc.)

rustup target install x86_64-unknown-linux-musl  # Or however you need to do it for your setup

cd /tmp
cargo new test-tarpaulin
cd test-tarpaulin

cat <<EOF >src/main.rs
fn a()  {
    if unsafe { libc::getpid() } < 0 {
        panic!("{}", std::io::Error::last_os_error());
    }
}
EOF
echo 'libc = "0.2"' >>Cargo.toml

cargo tarpaulin --target=x86_64-unknown-linux-musl --verbose

What should happen

tarpaulin builds the target and runs successfully. (It worked with tarpaulin v0.16.0.)

What actually happens

tarpaulin fails with a message about a segfault.

Nov 11 16:45:29.104 DEBUG cargo_tarpaulin: set up logging
Nov 11 16:45:29.104  INFO cargo_tarpaulin::config: Creating config
Nov 11 16:45:29.118  INFO cargo_tarpaulin: Running Tarpaulin
Nov 11 16:45:29.118  INFO cargo_tarpaulin: Building project
   Compiling bitflags v1.2.1
   Compiling libc v0.2.80
   Compiling test-tarpaulin v0.1.0 (/tmp/test-tarpaulin)
    Finished test [unoptimized + debuginfo] target(s) in 1.08s
Nov 11 16:45:30.257  INFO cargo_tarpaulin: Launching test
Nov 11 16:45:30.257  INFO cargo_tarpaulin: running /tmp/test-tarpaulin/target/x86_64-unknown-linux-musl/debug/deps/test_tarpaulin-86c594765747da0f
Nov 11 16:45:30.534 ERROR cargo_tarpaulin: Failed to get test coverage! Error: Failed to run tests: A segfault occurred while executing tests
Error: "Failed to get test coverage! Error: Failed to run tests: A segfault occurred while executing tests

I’m not familiar with tarpaulin’s internals (not by a long shot 😃, so I can’t debug this any further.

Environment

I’ve been able to reproduce this on Arch Linux, Void Linux, and Ubuntu (all three had rustc 1.47.0 and were running either the latest kernel from the repos or only a few revisions behind).

Potential cause

It looks like this regression was caused (at least, most directly) by #613. RUSTFLAGS='-C relocation-model=dynamic-no-pic' cargo tarpaulin --target=x86_64-unknown-linux-musl --verbose builds with no problems.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 18 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Okay I’ve figured out the musl bug, I just need to implement it. In the process memory map it adds vvar and vDSO before the executable which is I guess the memory map info for musl itself. glibc the process is always first which I thought should hold for everything.

I’ll fix this and also add a test for musl binaries to avoid regressions.

After sleeping on it I think I have a solution for the other problem I just need to do some experimentation 😄

So I have a potential fix for everything on the fix_unhandled_tids branch. I’ll test it on zcash tomorrow, it just started to pass my minimal repo at midnight here so I didn’t want to start running another test that takes a longer time

I think there are two bugs here, I musl seems to cause very large address offsets to be reported which I think is leading to mis-instrumentation.

For @MitMaro and @xiye518 I cant map the thread id to a parent pid with the new exec aware tracing. If I stub it so if it fails it’s always the root test id it seems to always work… But that may then break tests that trace execs. If I can’t find a better solution by the end of the week I’ll release a patch doing that, after all having a new feature break some projects that use it is better than breaking existing projects.

@cptpcrd your issue should be fixed in develop if you want to try that.

@MitMaro @xiye518 I have a possible solution in the branch fix_unhandled_tids, it works for git-interactive-rebase but it seems to timeout in zebra still (although still performs better). So still investigating it

@xd009642 , just gave the branch and try and I can confirm that it works. Thanks for the quick update! Hopefully, the timeout issue isn’t too difficult. 😃