Change:
} else { "rust_eh_personality" }; <del> let fty = self.type_variadic_func(&[], self.type_i32()); self.declare_cfn(name, llvm::UnnamedAddr::Global, fty) </del> <ins> if let Some(llfn) = self.get_declared_value(name) { llfn } else { let fty = self.type_variadic_func(&[], self.type_i32()); let llfn = self.declare_cfn(name, llvm::UnnamedAddr::Global, fty); attributes::apply_target_cpu_attr(self, llfn); llfn } </ins> } }; <del> attributes::apply_target_cpu_attr(self, llfn); </del> self.eh_personality.set(Some(llfn)); llfn }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: and gdb backtrace with 1.42.0 gdb backtrace with 1.43.0-nightly ( 2020-03-11)
oops, corrected backtrace of nightly.. pasted the stable output again.
can you share the code that causes this issue?.
triage: we couldn't decide the priority of the issue due to the lack of code. Left nomination so we can check again once we have the code that triggers the issue.
ping cleanup-crew
Error: This team () cannot be pinged via this command;it may need to be to on the master branch. Please let know if you're having trouble with this bot.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
in T-compiler meeting. Prioritizing as P-high for the initial investigation into what's going on. (It may or may not deserve a higher or lower priority once we figure out where the segfault is coming from...)
could be replaced with
updated the branch again, so the assembler code compiles with more toolchains
are you guys able to reproduce this, or is this only happening with my kernel+glibc+whatever combination?
Backtrace: looks suspicious and I sort of confirmed it: works fine but crashes. cc
modify labels: +regression-from-stable-to-stable
Error: Label regression-from-stable-to-stable can only be set by Rust team members Please let know if you're having trouble with this bot.
that looks like a blocked thread, not a segfaulting threading. You'll likely want to get the backtrace of all threads if you're seeing a crash, and the ones that aren't blocked in pthreads are likely the ones segfaulting.

Or if it is indeed segfaulting in pthreads, it would be good to confirm that by inspecting the instruction to see what the faulting instruction was, since that could hint to possible data corruption via jobserver stuff, but I'm pretty doubtful that's the cause here given the original backtrace in the OP. This seems unrelated to jobserver stuff from what I'm reading, so I'm going to unsubscribe myself. Feel free to ping me again if it's more confirmed though that jobserver stuff is at fault.
Still an issue.. this time with released "stable"
$ sudo apt-get install musl-tools $ git clone --single-branch -b rust_segfault $ cd enarx/enarx-keep-sev-shim $ while cargo build -vvv --release ; do cargo clean; done;
And it's segfaulting way more often, than succeeding.
for a successful build I have to do:
There is a mismatch between declared by rustc (which has return type and variadic arguments) and one from the crate. The issue can be reproduced with code below, but observing it might require enabled LLVM assertions: Using the same type signature seems to work fine, although it requires ZST to workaround requirement for at least one named argument.
Oh, you are right.. I can totally remove it and it does not segfault anymore! Thanks!
so, I to because it's only needed in the debug profile, and seems to cause the segfault in release.
Hi folks, I think I encountered the same issue, I've commented with a similar stacktrace.