rustc 1.12.0 fails with SIGSEGV in release mode (syn crate 0.8.0)

[svend]

To reproduce:

# Install rust 1.12.0
git clone https://github.com/dtolnay/syn.git
cd syn.git
git checkout 0.8.0
cargo build --release --verbose

I expect this to compile, instead it fails with:

$ cargo build --release --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling quote v0.2.0
     Running `rustc /home/ubuntu/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/quote-0.2.0/src/lib.rs --crate-name quote --crate-type lib -C opt-level=3 -C metadata=9442466506b24325 -C extra-filename=-9442466506b24325 --out-dir /home/ubuntu/syn/target/release/deps --emit=dep-info,link -L dependency=/home/ubuntu/syn/target/release/deps --cap-lints allow`
   Compiling syn v0.8.0 (file:///home/ubuntu/syn)
     Running `rustc src/lib.rs --crate-name syn --crate-type lib -C opt-level=3 --cfg feature=\"default\" --cfg feature=\"quote\" --cfg feature=\"printing\" --cfg feature=\"parsing\" -C metadata=977935f812d0e598 --out-dir /home/ubuntu/syn/target/release/deps --emit=dep-info,link -L dependency=/home/ubuntu/syn/target/release/deps --extern quote=/home/ubuntu/syn/target/release/deps/libquote-9442466506b24325.rlib`
error: Could not compile `syn`.

Caused by:
  Process didn't exit successfully: `rustc src/lib.rs --crate-name syn --crate-type lib -C opt-level=3 --cfg feature="default" --cfg feature="quote" --cfg feature="printing" --cfg feature="parsing" -C metadata=977935f812d0e598 --out-dir /home/ubuntu/syn/target/release/deps --emit=dep-info,link -L dependency=/home/ubuntu/syn/target/release/deps --extern quote=/home/ubuntu/syn/target/release/deps/libquote-9442466506b24325.rlib` (signal: 11, SIGSEGV: invalid memory reference)

Running the rustc command by hand results in a core dump:

$ rustc src/lib.rs --crate-name syn --crate-type lib -C opt-level=3 --cfg feature=\"parsing\" --cfg feature=\"default\" --cfg feature=\"printing\" --cfg feature=\"quote\" -C metadata=977935f812d0e598 --out-dir /home/ubuntu/syn/target/release/deps --emit=dep-info,link -L dependency=/home/ubuntu/syn/target/release/deps --extern quote=/home/ubuntu/syn/target/release/deps/libquote-9442466506b24325.rlib
Segmentation fault (core dumped)

rustc version:

$ rustc --version --verbose
rustc 1.11.0 (9b21dcd6a 2016-08-15)
binary: rustc
commit-hash: 9b21dcd6a89f38e8ceccb2ede8c9027cb409f6e3
commit-date: 2016-08-15
host: x86_64-unknown-linux-gnu
release: 1.11.0

I cannot reproduce this failure with 1.11.0.

In the rustc irc channel, it was noted that this fixed in beta already, and that the following backtrace (from https://gist.github.com/nagisa/682b493e40729c1f322966f8c21e00c6) would be relevant:

#0  0x00007ffff2ec4557 in llvm::InstVisitor<llvm::InstCombiner, llvm::Instruction*>::visit(llvm::Instruction&) () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#1  0x00007ffff2ec4a08 in llvm::InstCombiner::run() () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#2  0x00007ffff2ec627c in combineInstructionsOverFunction(llvm::Function&, llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::DominatorTree&, bool, llvm::LoopInfo*) ()
   from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#3  0x00007ffff2ec64a8 in llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#4  0x00007ffff34062af in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#5  0x00007ffff30e3d27 in (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#6  0x00007ffff3405f1f in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#7  0x00007ffff339db29 in LLVMRunPassManager () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_llvm-40393716.so
#8  0x00007ffff6867205 in rustc_trans::back::write::execute_work_item::h16483495753d2a00 () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_trans-40393716.so
#9  0x00007ffff6861ebf in rustc_trans::back::write::run_passes::hfe2f5491c3937c7d () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_trans-40393716.so
#10 0x00007ffff7b3b590 in rustc_driver::driver::phase_5_run_llvm_passes::hebb06729f3c92d6e () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-40393716.so
#11 0x00007ffff7b24191 in rustc_driver::driver::compile_input::h4d6bc655b7baad10 () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-40393716.so
#12 0x00007ffff7b50777 in rustc_driver::run_compiler::h9165e61fc2dd486f () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-40393716.so
#13 0x00007ffff7a976e3 in std::panicking::try::do_call::hc52dd3bdae996640 () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-40393716.so
#14 0x00007ffff7794747 in __rust_maybe_catch_panic () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/libstd-40393716.so
#15 0x00007ffff7ab0d7b in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h3aad53cfb9d2713a () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-40393716.so
#16 0x00007ffff7782d33 in std::sys::thread::Thread::new::thread_start::h4c0ad33b336bc6ea () from /home/nagisa/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/libstd-40393716.so
#17 0x00007ffff0731454 in start_thread () from /usr/lib/libpthread.so.0
#18 0x00007ffff73d37df in clone () from /usr/lib/libc.so.6

[dtolnay]

Steps for minimal repro:

$ cargo init repro
$ cd repro
$ echo 'pub fn f() { let _: Vec<char> = "x".chars().collect(); }' > src/lib.rs
$ rustup run 1.12.0 cargo build --release --verbose

[bluss]

1.11 -> 1.12 regression since it used to work dtolnay/syn#20 (comment)

[nikomatsakis]

In the rustc irc channel, it was noted that this fixed in beta already, and that the following backtrace would be relevant

Sorry, I'm confused. Ah, I guess you mean that this is fixed in the 1.13 beta?

[nikomatsakis]

I can confirm that this works on the beta channel (1.13) but fails on the stable channel (1.12). I don't know what patch would need to be backported (maybe someone from @rust-lang/compiler recognizes the backtrace?), but I'm inclined to downgrade the priority here as a result.

Thoughts?

[eddyb]

Can we get an assertion message of any kind? That could confirm it's a specific bug or another.

[nikomatsakis]

@eddyb i.e., rebuild rust with LLVM assertions enabled?

[eddyb]

@nikomatsakis Using a nightly that's about as old as the release (i.e. 12 weeks ago) should work.

[nikomatsakis]

@eddyb ah very good, will do

UPDATE:

• works on 2016-07-27
• works on 2016-08-01
• testing on 2016-07-15

[eddyb]

@nikomatsakis It could be one of the backports, in which case beta might work? Not sure if it has LLVM assertions enabled though (cc @alexcrichton).

[alexcrichton]

I believe betas don't have LLVM assertions enabled unfortunately

[brson]

I'll try a local beta build with asserts and see if i can bisect the patch that fixes.

[brson]

I have not been able to reproduce this with a local build of 1.12.

[brson]

I'm worried that this failure is an artifact of our release build environment and am trying to reproduce it there.

[brson]

I've reproduced this inside the docker image we used for the 1.12 release:

sudo docker run --entrypoint bash -it alexcrichton/rust-slave-dist:2016-07-14

This image has since had a significant upgrade. I have no idea what thing changed to make the problem go away.

This does suggest a risk of doing a 1.12 point release: our build environment has changed significantly.

I'm going to leave this open until we've thought about a 1.12 point release, but I think there's nothing left to do here.