Stream: t-compiler

Topic: sigsegvs


nagisa (Aug 07 2018 at 10:21, on Zulip):

It appears to be fairly commonplace for the compiler to segfault lately (#53149, #53099, #53083, #52884). My bet is on LLVM assertion firing, but since they are not enabled, it is not clear what it is that we’re dealing with.

nagisa (Aug 07 2018 at 10:22, on Zulip):

we probbaly should have an easier method to try LLVM with assertions, possibly as a separate codegen backend :slight_smile:

pnkfelix (Aug 07 2018 at 10:46, on Zulip):

In the period leading up to an LLVM upgrade and immediate following it, we probably should enable LLVM assertions, no?

pnkfelix (Aug 07 2018 at 10:46, on Zulip):

At least, it seems like it would be a good way to try to catch issues.

pnkfelix (Aug 07 2018 at 10:47, on Zulip):

but then again, for all I know people do re-enable LLVM assertions when testing an upgrade locally

mw (Aug 07 2018 at 11:28, on Zulip):

I usually have them enabled for all my local builds

pnkfelix (Aug 07 2018 at 11:31, on Zulip):

i think I used to do that, but then I got frustrated because the ones that were asserting on master weren't getting fixed

RalfJ (Aug 07 2018 at 11:37, on Zulip):

We do have CI runners with LLVM assertions enabled though, don't we?

nikomatsakis (Aug 07 2018 at 11:44, on Zulip):

It appears to be fairly commonplace for the compiler to segfault lately (#53149, #53099, #53083, #52884). My bet is on LLVM assertion firing, but since they are not enabled, it is not clear what it is that we’re dealing with.

seems bad... I wonder how we can test this theory most effectively?

nikomatsakis (Aug 07 2018 at 11:44, on Zulip):

is there an easy way for us to tell people to enable assertions?

nagisa (Aug 07 2018 at 12:17, on Zulip):

No, but we could have one by building a codegen backend that has assertions enabled, in addition to our current backend that doesn’t. Since the backend is just a shared library, conceiving a method for swapping it out should be not too hard.

nagisa (Aug 07 2018 at 12:18, on Zulip):

Alas, the backend is full of extern "Rust" functions IIRC, which makes it not really portable.

nikomatsakis (Aug 07 2018 at 12:31, on Zulip):

No, but we could have one by building a codegen backend that has assertions enabled, in addition to our current backend that doesn’t. Since the backend is just a shared library, conceiving a method for swapping it out should be not too hard.

interesting

nikomatsakis (Aug 07 2018 at 12:31, on Zulip):

@nagisa portable in what sense?

nagisa (Aug 07 2018 at 12:38, on Zulip):

in a sense of having a single .so for a single version of LLVM that can be used across many versions of rustc.

nikomatsakis (Aug 07 2018 at 12:39, on Zulip):

ah ok

simulacrum (Aug 07 2018 at 14:09, on Zulip):

We have 64bit linux binaries with LLVM asserts for each commit

simulacrum (Aug 07 2018 at 14:10, on Zulip):

No good way to get them via rustup but https://crates.io/crates/rustup-toolchain-install-master can do it (--alt flag I believe)

simulacrum (Aug 07 2018 at 14:10, on Zulip):

I think we might be able to ship two backends like we do with emscripten and normal LLVM, adding a assertions-enabled backend that can be enabled via some environment variable or compiler flag

nagisa (Aug 07 2018 at 17:56, on Zulip):

but we don’t really want to do that, could as well just ship assertion enabled nightlies in that case

nagisa (Aug 07 2018 at 17:56, on Zulip):

There are many reasons we disabled assertions in nightlies in the first place and shipping multiple llvms just for assertions would defeat about 99% of those reasons.

simulacrum (Aug 07 2018 at 18:11, on Zulip):

I think most had to do with performance so a switch-enabled assertion build might not be too bad

nikomatsakis (Aug 07 2018 at 18:49, on Zulip):

I thought it was primarily driven by perf, yeah

nikomatsakis (Aug 07 2018 at 18:50, on Zulip):

that said, how certain are we that LLVM assertions are relevant here?

nikomatsakis (Aug 07 2018 at 18:50, on Zulip):

is there a way to test that hypothesis?

nagisa (Aug 07 2018 at 18:53, on Zulip):

Well, I know for sure that LLVM, when assertions are disabled, just replaces them with a trap. So, usually, when I see a SIGSEGV or SIGILL in LLVM somewhere (some of those issues have LLVM in their backtraces) I’m fairly confident in it being an assert.

nikomatsakis (Aug 07 2018 at 20:06, on Zulip):

I guess what I meant is, is there some mechanism (e.g., alt-builds?) we can use today to reproduce this?

simulacrum (Aug 07 2018 at 20:12, on Zulip):

We do have alt builds for every commit, which have LLVM asserts enabled. I'm not sure how much that helps, though...

Last update: Nov 21 2019 at 14:40UTC