Segfault on latest nightly with codegen-units > 1

[jonhoo]

On the latest nightly, the default is now to run release builds with codegen-units > 1 (see #46910). For some reason, this causes https://github.com/mit-pdos/distributary to segfault at runtime. Setting

[profile.release]
codegen-units = 1

makes the segfault go away. To reproduce:

$ rustc +nightly --version
rustc 1.25.0-nightly (f62f77403 2018-01-10)
$ git clone https://github.com/mit-pdos/distributary.git
$ cd distributary
$ git checkout open-loop
$ cargo +nightly b --release --manifest-path benchmarks/Cargo.toml --bin vote
$ target/release/vote -r 5 --target 100000 localsoup
Segmentation fault (core dumped)
$ # add codegen-units = 1 to Cargo.toml under [profile.release]
$ cargo +nightly b --release --manifest-path benchmarks/Cargo.toml --bin vote
$ target/release/vote -r 5 --target 100000 localsoup
# wait ~5s and notice that it completes without crashing

[nagisa]

Cannot reproduce on Linux with exactly the same rustc:

rustc 1.25.0-nightly (f62f774 2018-01-10)

I even went out of my way to compile with a number of different flags. What happens instead is:

thread 'main' panicked at 'no entry found for key', libcore/option.rs:891:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:68
             at libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: rust_begin_unwind
             at libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   9: core::option::expect_failed
             at libcore/option.rs:891
  10: vote::clients::localsoup::graph::make
             at /checkout/src/libcore/option.rs:302
             at /checkout/src/liballoc/btree/map.rs:1753
             at benchmarks/vote/clients/../../vote-old/graph.rs:149
  11: vote::run
             at benchmarks/vote/clients/localsoup.rs:55
             at benchmarks/vote/main.rs:50
  12: vote::main
             at benchmarks/vote/main.rs:441
  13: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  14: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  15: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  16: std::rt::lang_start_internal
             at libstd/panicking.rs:458
             at libstd/panic.rs:365
             at libstd/rt.rs:58
  17: main
  18: __libc_start_main
  19: _start

right after executable is started. This makes me suspect there might be UB-invoking code.

Please provide more information, and a test case as minimal as possible.

[jonhoo]

That's very interesting... I was compiling with some special RUSTFLAGS (specifically with ld-gold and -Cnative), but even withenv RUSTFLAGS= cargo b I observe the segfault. Are you sure you didn't accidentally also build with 8b973c8480cf0cbd51746458bbe4d426451cfbbc (which I pushed yesterday to the open-loop branch and sets codegen-units=1 by default)? Also, I never see the crash you reported above, so clearly something weird is going on (and you may be right that it's UB :/)

I'd love to give a smaller replicating example, but this is a pretty large codebase, so reducing becomes tricky. Do you have a recommendation for where I should start looking/pruning?

[nagisa]

So, I was including your commit most recent commit, but I also made sure to set some -Ccodegen-units=4, because the issue report claims it reproduces > 1. That’s where the panic happens. With -Ccodegen-units=16 or -Ccodegen-units=12 I see the SIGSEGV.

It seems to me like it would be easier to reduce the panic above, as the backtrace seems fairly local to your benchmark executable, but you could work on reducing for the sigsegv as well. I often begin reducing by blindly removing non-critical components piecemeal. For example one of the first components I’d remove would be argument parsing (and so -- the fairly large dependency on clap) and hardcoding the arguments used to reproduce.

[jonhoo]

I'll try that. Curiously enough, I still see the SIGSEGV even with codegen-units = 4, but I'll just have to work with it.

[jonhoo]

Here's a start:

extern crate nom_sql;

fn main() {
    let r_txt = "SELECT Article.id, title, VoteCount.votes AS votes \
                            FROM Article \
                            LEFT JOIN (SELECT Vote.id, COUNT(user) AS votes \
                                       FROM Vote GROUP BY Vote.id) AS VoteCount \
                            ON (Article.id = VoteCount.id) WHERE Article.id = ?";
    nom_sql::parser::parse_query(r_txt);
}

This segfaults with 4 units, though only some of the time. Depends only on the nom-sql crate. I'll keep digging.

[jonhoo]

The smallest reproducing example I've been able to come up with thus far can be found at https://github.com/jonhoo/rust-issue-47364. Just run cargo run --release with nightly. That code has no unsafe (though I suppose nom probably does?).

[jonhoo]

Now down to:

#[macro_use]
extern crate nom; // nom = "1.2.4" in [dependencies]
use nom::multispace;

pub enum ConditionExpression {
    Field(String),
    Placeholder,
}

pub fn condition_expr<'a>(i: &'a [u8]) -> nom::IResult<&[u8], ConditionExpression, u32> {
    nom::IResult::Done(i, ConditionExpression::Placeholder)
}

named!(pub selection<&[u8], Option<ConditionExpression>>,
    chain!(
        select: chain!(
            tag!("x") ~
            cond: opt!(complete!(chain!(
                multispace? ~
                cond: condition_expr,
                || { cond }
            ))) ~
            || { cond }
        ) ~
        tag!(";"),
        || { select }
    )
);

fn main() {
    selection("x ".as_bytes());
}

I don't know that I can minimize much more without starting to dig into nom (and an outdated one at that...)

[jonhoo]

@nagisa I've now pruned a bunch of the code from nom as well. The linked repository (https://github.com/jonhoo/rust-issue-47364) has no external dependencies, and no unsafe code, but still segfaults if you run do cargo +nightly r --release.