Change:
<del> Subproject commit 9f65ad057357b307180955831968f79e74090a90 </del> <ins> Subproject commit 992e608cfc5d1c126a23c640222fd396a3bdeb9f </ins>

Discussion:
Instructions to reproduce: - - The build script of segfaults. The actual function with the bug is an instance in the procmacro2 crate. The cause seems to be an LLVM bug. This LLVM IR is generated: asm .LBB2714: // This is never executed .loc 27 0 15 isstmt 0 movq 160(%rsp), %rcx movl $1, %esi .Ltmp379: // Landing pad points to here!!! leaq _llvmgcovctr.27(%rip), %rdi addq $120, %rdi .loc 27 274 15 movq (%rcx), %r8 addq $1, %r8 movq %r8, (%rcx) So basically the initialization of is getting skipped by the incorrect landing pad, which in turn causes the crash. Edit by original bug report follows. Just updated nightly on my CI machine and found out that tests stopped compiling few of dependencies like cssparser or stringcache or html5ever. It probably happens because of my RUSTFLAGS I created repository with reproduction Bissect found that this PR introduced this issue
cc perhaps related to
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 instead of ?
will cause to be optimized away with the new implementation. This is why the runtime can't initiate a panic: it can't find a catch for the exception. I would recommend either using or just removing .
Changed my RUSTFLAGS to and still crashes.
Minimal reproduction: Clone rust-lang/libc Output: cargo-bisect-rustc points to 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
introduced extra calls to Handle::intonode (the function that the profiler is trying to talk about) in case of panic, that would come into play in shouldpanic 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 shouldpanic test cases in PS That doesn't add up - the problem fixed was pointed out by Miri, so it must be able to run shouldpanic tests now. Or something.
Nevermind that's a false positive. It seems that requires to work properly. The issue is unrelated to the btree code.
OK I think I've narrowed it down to an LLVM bug. This LLVM IR is generated: asm .LBB2714: // This is never executed .loc 27 0 15 isstmt 0 movq 160(%rsp), %rcx movl $1, %esi .Ltmp379: // Landing pad points to here!!! leaq _llvmgcov_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 is getting skipped by the incorrect landing pad, which in turn causes the crash.
Unnominating since this requires an unstable compiler flag to trigger
Instructions to reproduce: - (NOTE: will cause the bug to no longer trigger) The actual function with the bug is an instance in the procmacro2 crate.
basically disables because no gcda files are generated. This miscompilation is kinda sad because mozilla's grcov is the most reliable coverage tool for rust. And if you want to have your rust application very well tested coverage is kinda important. I will probably stick to until It's not fixed but I can't use it indefinitely.
LLVM bug:
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. PS and yes, with today's nightly Miri these tests succeed just like any other.

I thought they didn't a month ago or so (memory leaks).
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: