LLVM generates incorrect code with -Zprofile #70148
Comments
Lesiuk
added
C-bug
|
Is there a reason you're passing -Zno-landing-pads? I believe in ~all cases you should either be doing -Cpanic=abort today, no-landing-pads is likely to lead to problems... but it would be odd for that to lead to trouble in the compiler I think |
|
Yes. I just updated my description of the issue. Bissect found this PR. |
|
Those flags are recommended by mozilla's grcov tool: |
|
Does this problem still happen with |
|
I would recommend either using |
jonas-schievink
added
A-runtime
|
Changed my RUSTFLAGS to
and still crashes. |
Mark-Simulacrum
added
the
E-needs-mcve
|
Minimal reproduction:
Output: cargo-bisect-rustc points to e2223c9 as the source of the regression, which seems a bit surprising. |
|
I'm not familiar with -Zprofile -- but I agree that seems like a surprising trace. It's not implausible that there's some bug introduced by that, though, given the heavy use of unsafe code in BTree... Maybe we could get a stack trace on the SIGSEGV? |
It does look related to the BTree stuff. |
|
cc @ssomers |
|
#69776 introduced extra calls to Handle::into_node (the function that the profiler is trying to talk about) in case of panic, that would come into play in should_panic test cases (that are excluded by Miri, and don't count on me knowing exactly what happens there). So you might want to try excluding the bunch of should_panic test cases in liballoc/tests/btree/map.rs PS That doesn't add up - the problem fixed was pointed out by Miri, so it must be able to run should_panic tests now. Or something. |
|
Nevermind that's a false positive. It seems that |
|
OK I think I've narrowed it down to an LLVM bug. This LLVM IR is generated: catch.i: ; preds = %.noexc
%120 = phi i64* [ getelementptr inbounds ([24 x i64], [24 x i64]* @__llvm_gcov_ctr.27, i64 0, i64 11), %.noexc ], !dbg !2861
%121 = landingpad { i8*, i32 }
catch i8* null, !dbg !2861
%122 = load i64, i64* %120, !dbg !2861
%123 = add i64 %122, 1, !dbg !2861
store i64 %123, i64* %120, !dbg !2861```Notice how the .LBB27_14: // This is never executed
.loc 27 0 15 is_stmt 0
movq 160(%rsp), %rcx
movl $1, %esi
.Ltmp379: // Landing pad points to here!!!
leaq __llvm_gcov_ctr.27(%rip), %rdi
addq $120, %rdi
.loc 27 274 15
movq (%rcx), %r8
addq $1, %r8
movq %r8, (%rcx)So basically the initialization of |
jonas-schievink
added
A-LLVM
|
Unnominating since this requires an unstable compiler flag to trigger |
|
Instructions to reproduce:
The actual function with the bug is an instance |
|
I will probably stick to |
Amanieu
changed the title
Miri has supported panics for a while now. If there are still panic tests excluded by Miri, that's a bug. Do you have an example of such a test? |
|
Never mind, I excluded should_panic tests when testing myself, since I don't know how to run them successfully. |
AFAICT using these flags is the only way to get code coverage reporting working. A lot of projects (all that I've been associated with) build everything with stable Rust but then do code coverage using nightly Rust + these unstable flags. Temporarily I've reverted back to a 2020-03-11 nightly for this as a workaround, but that workaround will stop working effectively in once Stable Rust is no longer a subset of the nightly-2020-03-11 feature set. |
|
Fixed in LLVM: rust-lang/llvm-project@e5bf503 |
Instructions to reproduce:
git clone [email protected]:servo/html5ever.gitcd html5ever/markup5everCARGO_INCREMENTAL=0 RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Cinline-threshold=0" cargo checkmarkup5eversegfaults.The actual function with the bug is an instance
std::panicking::tryin the proc_macro2 crate.The cause seems to be an LLVM bug.
full gist
This LLVM IR is generated:
Notice how the
phiis inserted before thelandingpadinstruction. This causes the following asm to be generated:So basically the initialization of
%rcxis getting skipped by the incorrect landing pad, which in turn causes the crash.Edit by @Amanieu, original bug report follows.
Just updated nightly on my CI machine
and found out that tests stopped compiling few of dependencies like cssparser or string_cache or html5ever.
It probably happens because of my RUSTFLAGS
I created repository with reproduction
https://github.com/Lesiuk/rust-nightly-issue-reproduction
Bissect found that this PR introduced this issue #67502
Log from test run
The text was updated successfully, but these errors were encountered: