Closed fsavy-tehtris closed 10 months ago
cc @Zalathar
I was able to reproduce this on beta+nightly on my machine (macOS aarch64), so I should be able to dig into the mappings and see what LLVM is complaining about.
(Thanks for the detailed report!)
This seems to be where the Malformed coverage data
error is coming from:
When the error occurs in the above code, we have startLoc = (159, 59) and endLoc = (1, 4), causing the check to fail.
That seems to correspond to this code:
If I print out the raw values being read by readMappingRegionsSubArray
, I see:
[RAW] LineStartDelta = 159; ColumnStart = 59; NumLines = 4294967138; ColumnEnd = 4
That NumLines value is 0xFFFFFF62, which is clearly bogus. Probably the result of integer overflow somewhere.
Actually I've traced the bogus (1, 4) coordinates to the actual span processed by make_code_region
.
It looks like maybe_push_macro_name_span
is producing a bogus span that extends into an adjacent file, completely trashing the span coordinates.
At this point I'm guessing the culprit is #116754.
Hmm, but I can reproduce this on nightly-2023-10-15
, which predates the merge of #116754, so I should look at changes earlier than that.
Manually bisected this down to 2023-09-05
(good) to 2023-09-06
(bad).
After some more manual bisection, I'm pretty sure this started failing after #115507. That seems consistent with it being a latent coverage bug that has now been made more common by compiler-wide changes to spans.
Even in prior revisions I can observe the spans created by check_invoked_macro_name_span
sometimes being bogus; they're just bogus in a way that tends not to result in malformed mappings and llvm-cov
failures.
(In this situation, cargo-bisect-rustc
should work fine to avoid bisecting manually)
The fix for this has been cherry-picked into the upcoming stable release of 1.74, and has also been merged on nightly (1.76).
It will probably still be broken in the initial version of the upcoming beta release (1.75); ideally the fix will also be be accepted on the beta branch at some point in the next 5 weeks.
Code
I tried to run
cargo llvm-cov
on this code:I expected the tool to work normally, but instead, this happened:
Please note this is the most minimal reproducible example I've been able to find.
Removing either the
no_mangle
attribute or theffi_panic_message
call does not reproduce the error, but theextern "C"
has not effect. I've tried to remove theabi_stable
dependency but putting the required code in the same file or in a different crate (in the same workspace) does not reproduce the error.Associated
abi_stable
codeVersion it worked on
It most recently worked on: 1.73.0
Version with regression
rustc --version --verbose
:@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged