Open
Description
I tried to use cov show
as a replacement for llvm-cov show
on the example C++ program from https://clang.llvm.org/docs/SourceBasedCodeCoverage.html but encountered the following panic:
thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 7', src/coverage/coverage_mapping.rs:514:13
stack backtrace:
0: rust_begin_unwind
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
2: core::panicking::panic_bounds_check
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:84:5
3: llvm_profparser::coverage::coverage_mapping::parse_counter
at ./src/coverage/coverage_mapping.rs:514:13
4: llvm_profparser::coverage::coverage_mapping::parse_mapping_regions
at ./src/coverage/coverage_mapping.rs:386:31
5: llvm_profparser::coverage::coverage_mapping::parse_coverage_functions
at ./src/coverage/coverage_mapping.rs:332:17
6: llvm_profparser::coverage::coverage_mapping::read_object_file::{{closure}}
at ./src/coverage/coverage_mapping.rs:70:18
7: core::option::Option<T>::map
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:929:29
8: llvm_profparser::coverage::coverage_mapping::read_object_file
at ./src/coverage/coverage_mapping.rs:67:19
9: llvm_profparser::coverage::coverage_mapping::CoverageMapping::new
at ./src/coverage/coverage_mapping.rs:107:31
10: cov::ShowCommand::run
at ./src/bin/cov.rs:46:23
11: cov::main
at ./src/bin/cov.rs:75:35
12: core::ops::function::FnOnce::call_once
at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
I know your project is mostly targeted for parsing profiling data from rust programs but since the coverage mapping format is the same it should work universally for other profdata too. Right?
Here are my steps to reproduce:
cd /tmp
git clone https://github.com/xd009642/llvm-profparser.git
cd llvm-profparser
cat <<EOF > foo.cc
#define BAR(x) ((x) || (x))
template <typename T> void foo(T x) {
for (unsigned I = 0; I < 10; ++I) { BAR(I); }
}
int main() {
foo<int>(0);
foo<float>(0);
return 0;
}
EOF
clang++ -fprofile-instr-generate -fcoverage-mapping foo.cc -o foo
LLVM_PROFILE_FILE="foo.profraw" ./foo
llvm-profdata merge -sparse foo.profraw -o foo.profdata
# Works
llvm-cov show ./foo -instr-profile=foo.profdata
# Works not
RUST_BACKTRACE=1 cargo run --bin cov -- show --instr-profile foo.profdata --object ./foo
OS: Arch Linux
Clang/LLVM version: 14.0.6
Any help to debug this further is highly appreciated!
Metadata
Assignees
Labels
No labels
Activity
xd009642 commentedon Nov 1, 2022
Yeah ideally it should work, it's probably a bug in some assumption I have - I just use the test files from llvm code that are easy to apply and some tests generated from rust code and the format isn't really rigorously defined so it's been a mix of reading the llvm source and reverse engineering solutions to issues from odd output I find in the wild and making sure output is the same.
I'll have a look after work and maybe look at adding some debug logging to aid in debugging 🙏
xd009642 commentedon Nov 6, 2022
There's now a branch called debug-traces with a
--debug
flag which will show a bunch of printouts. I don't have the same llvm on my system so I'll have to sort that out and test with the same version as you, but you can always use--debug
and see if that provides some more debug info.Or if you have it handy zip up the executable and profraw + profdata files from your minimal version and attach them to the issue and I'll try them out directly
danjujan commentedon Nov 7, 2022
Thank you. Here is the debug output and the corresponding files. foo-example.zip
xd009642 commentedon Mar 29, 2023
So a PR has just been merged which should fix this issue - something in branch regions which rust doesn't currently emit. I'm going to cut a new release later today or tomorrow so hopefully you can confirm this works for you then (if it's not been too long)
danjujan commentedon Mar 30, 2023
Current master does not fix it for me. However, the debug output changed and it does not crash anymore. So probably one step in the right direction!
xd009642 commentedon Mar 30, 2023
@Quessou looks like there's a bit more to this one if you want to continue with it 👀
Quessours commentedon Mar 30, 2023
I'll take a look at it tomorrow ! :)
Quessours commentedon Apr 3, 2023
Sorry for the time to answer ! 😅
Just for traceability : Bug was first observed on Clang/LLVM 14
This second issue on parsing seem to be on Clang/LLVM 15.
I tried to reproduce the issue with the same setup I used to fix the first issue and the parsing does not fail on my end.
So maybe it's another issue actually, in this case, maybe creating another ticket would be relevant ? Anyway I'll get LLVM 15, try to reproduce and if I manage to do so, investigate a bit.
danjujan commentedon Apr 3, 2023
I get the same error with clang14 under Arch.
Quessours commentedon Apr 4, 2023
I couldn't reproduce it on LLVM/Clang14. 😬
However I have your exact same issue on LLVM15, with the following crash stack :
I'm kinda busy today but I will investigate this in the upcoming days ! :)