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
- Pin the version of tarpaulin used for collecting coverage to 0.16.0 0.17.0 has a bug that causes segfaults: https://github.com/xd009642/tarpaulin/issues/618 — committed to ZcashFoundation/zebra by dconnolly 4 years ago
- Pin the version of tarpaulin used for collecting coverage to 0.16.0 0.17.0 has a bug that causes segfaults: https://github.com/xd009642/tarpaulin/issues/618 — committed to ZcashFoundation/zebra by dconnolly 4 years ago
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 timeI 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. 😃