Could not compile `core` with SIGSEGV: invalid memory reference

[indirect]

Hopefully I'm doing something really obviously wrong, but I'm having trouble getting avr-rust/blink to compile.

1. Check out avr-rust/rust#avr-support-1.39.0-4560ea788c
2. Follow the compilation instructions, install, toolchain link, blah blah
3. Check out avr-rust/blink and run: RUST_TARGET_PATH=`pwd` RUST_BACKTRACE=1 XARGO_RUST_SRC=$HOME/src/avr-rust/rust/src cargo xbuild --target avr-atmega328p --release

Get the SIGSEGV while compiling core:

Updating crates.io index Compiling core v0.0.0 (/Users/andre/src/avr-rust/rust/src/libcore) Compiling compiler_builtins v0.1.21 Compiling rustc-std-workspace-core v1.99.0 (/Users/andre/src/avr-rust/rust/src/tools/rustc-std-workspace-core) error: could not compile `core`.

Caused by:
process didn't exit successfully: rustc --edition=2018 --crate-name core /Users/andre/src/avr-rust/rust/src/libcore/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=c4eee7f38a624e7b -C extra-filename=-c4eee7f38a624e7b --out-dir /var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.Hw4H4cAozToc/target/avr-atmega328p/release/deps --target avr-atmega328p -L dependency=/var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.Hw4H4cAozToc/target/avr-atmega328p/release/deps -L dependency=/var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.Hw4H4cAozToc/target/release/deps (signal: 11, SIGSEGV: invalid memory reference)

The output with xargo is slightly different, but reports the same SIGSEGV

$ RUST_TARGET_PATH=`pwd` RUST_BACKTRACE=1 XARGO_RUST_SRC=$HOME/src/avr-rust/rust/src xargo build --target avr-atmega328p --release

warning: Patch rustc-std-workspace-alloc v1.99.0 (/Users/andre/src/avr-rust/rust/src/tools/rustc-std-workspace-alloc) was not used in the crate graph.
Patch rustc-std-workspace-core v1.99.0 (/Users/andre/src/avr-rust/rust/src/tools/rustc-std-workspace-core) was not used in the crate graph.
Patch rustc-std-workspace-std v1.99.0 (/Users/andre/src/avr-rust/rust/src/tools/rustc-std-workspace-std) was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run cargo update to use the new
version. This may also occur with an optional dependency that is not enabled.
Compiling core v0.0.0 (/Users/andre/src/avr-rust/rust/src/libcore)
error: could not compile core.

Caused by:
process didn't exit successfully: rustc --edition=2018 --crate-name core /Users/andre/src/avr-rust/rust/src/libcore/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=9ca9a62c0f5debaf -C extra-filename=-9ca9a62c0f5debaf --out-dir /var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.8EIsUXh7kaSi/target/avr-atmega328p/release/deps --target avr-atmega328p -L dependency=/var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.8EIsUXh7kaSi/target/avr-atmega328p/release/deps -L dependency=/var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.8EIsUXh7kaSi/target/release/deps --sysroot /Users/andre/.xargo -Z force-unstable-if-unmarked (signal: 11, SIGSEGV: invalid memory reference)
error: "cargo" "build" "--release" "--manifest-path" "/var/folders/qc/x0j95x2d6tgb4686by93p4b00000gn/T/xargo.8EIsUXh7kaSi/Cargo.toml" "--target" "avr-atmega328p" "-p" "core" failed with exit code: Some(101)
stack backtrace:
0: backtrace::backtrace::trace
1: backtrace::capture::Backtrace::new
2: error_chain::make_backtrace
3: <error_chain::State as core::default::Default>::default
4: <std::process::Command as xargo::extensions::CommandExt>::run
5: xargo::sysroot::build
6: xargo::sysroot::update
7: xargo::main
8: std::rt::lang_start::{{closure}}
9: std::panicking::try::do_call
10: __rust_maybe_catch_panic
11: std::rt::lang_start_internal
12: main

Can anyone tell me what I'm doing wrong, or how to get more information about how exactly the SIGSEGV is happening?

[dylanmckay]

I'm hitting this too in #155.

[shepmaster]

or how to get more information about how exactly the SIGSEGV is happening?

For this kind of problem, I've usually resorted to running rustc in a debugger (GDB / LLDB). You have to be careful to run the right rustc, as there are wrapper rustcs as part of rustup.

[indirect]

Whoa, I finally got blink to build! 😮 The specific combination that got me past the error in this issue was:

• add RUSTFLAGS='-C opt-level=s' based on this comment
• only use xcargo build

If I don't include RUSTFLAGS, or if I do but use cargo xbuild instead... it gives me the error above. Huh. I guess I will call this resolved, for at least some value of resolved. Thanks everyone!

[dylanmckay]

I wanna keep this one open until we can fix the segfault in the greedy register allocator.

[Rahix]

For reference (although I already posted it in the other thread), the stack-trace of the segfault is this:

#0  0x00007f4fde5b1cc7 in (anonymous namespace)::RAGreedy::addSplitConstraints(llvm::InterferenceCache::Cursor, llvm::BlockFrequency&) [clone .isra.0] () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#1  0x00007f4fde5ba5a5 in (anonymous namespace)::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&, llvm::SmallVectorImpl<unsigned int>&, llvm::SmallSet<unsigned int, 16u, std::less<unsigned int> >&, unsigned int) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#2  0x00007f4fde5bbf68 in (anonymous namespace)::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl<unsigned int>&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#3  0x00007f4fde5a1c80 in llvm::RegAllocBase::allocatePhysRegs() () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#4  0x00007f4fde5b4001 in (anonymous namespace)::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#5  0x00007f4fde4af7d3 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#6  0x00007f4fdf0bc778 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#7  0x00007f4fdf0bc801 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#8  0x00007f4fdf0bbac8 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#9  0x00007f4fdd7a92a6 in LLVMRustWriteOutputFile () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#10 0x00007f4fdd74729c in rustc_codegen_llvm::back::write::write_output_file () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#11 0x00007f4fdd66e180 in rustc_codegen_llvm::back::write::codegen::{{closure}} () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#12 0x00007f4fdd663731 in rustc::util::common::time_ext () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#13 0x00007f4fdd75879b in <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::write::WriteBackendMethods>::codegen () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#14 0x00007f4fdd637058 in rustc_codegen_ssa::back::write::execute_work_item () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#15 0x00007f4fdd6fda56 in std::sys_common::backtrace::__rust_begin_short_backtrace () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#16 0x00007f4fdd65d754 in std::panicking::try::do_call () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#17 0x00007f4fe72a000a in __rust_maybe_catch_panic () from /build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-34dd0cab9bff80f1.so
#18 0x00007f4fdd65def3 in core::ops::function::FnOnce::call_once{{vtable-shim}} () from /build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#19 0x00007f4fe7299a5f in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once () from /build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-34dd0cab9bff80f1.so
#20 0x00007f4fe726c2d0 in std::sys_common::thread::start_thread () from /build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-34dd0cab9bff80f1.so
#21 0x00007f4fe729cdb6 in std::sys::unix::thread::Thread::new::thread_start () from /build/x86_64-unknown-linux-gnu/stage1/bin/../lib/libstd-34dd0cab9bff80f1.so
#22 0x00007f4fe6f4f4cf in start_thread () from /usr/lib/libpthread.so.0
#23 0x00007f4fe70f52d3 in clone () from /usr/lib/libc.so.6

[dylanmckay]

only use xcargo build

I agree, Xargo has not kept up to date with Rust's move of Cargo.lock from rust/src folder to top-level rust folder, it cannot compile blink.

[dylanmckay]

Here are LLVM IR and bitcode files for libcore under the avr-support-upstream branch which has this bug.

core.bc.txt
core.ll.txt

When I compile this with llc -march=avr -mcpu=atmega328 using upstream LLVM, I get this error

Impossible reg-to-reg copy                                                                                                                                                                    
UNREACHABLE executed at /home/dylan/projects/llvm/llvm-project/llvm/lib/Target/AVR/AVRInstrInfo.cpp:74!                                                                                       
Stack dump:                                                                                                                                                                                   
0.      Program arguments: ./bin/llc -march=avr -mcpu=atmega328 /tmp/foobar/core.ll -o /dev/null -O3                                                                                          
1.      Running pass 'Function Pass Manager' on module '/tmp/foobar/core.ll'.                                                                                                                 
2.      Running pass 'Post-RA pseudo instruction expansion pass' on function '@_ZN4core3num7flt2dec8strategy5grisu22max_pow10_no_more_than17hbf899851c170c742E'                               
 #0 0x00007fa0c9a167e5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/dylan/projects/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:22                                         
 #1 0x00007fa0c9a16878 PrintStackTraceSignalHandler(void*) /home/dylan/projects/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1                                                     
 #2 0x00007fa0c9a14621 llvm::sys::RunSignalHandlers() /home/dylan/projects/llvm/llvm-project/llvm/lib/Support/Signals.cpp:68:20                                                               
 #3 0x00007fa0c9a16165 SignalHandler(int) /home/dylan/projects/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1                                                                      
 #4 0x00007fa0cdfe7800 __restore_rt (/usr/lib/libpthread.so.0+0x14800)                                                                                                                        
 #5 0x00007fa0c912bce5 raise (/usr/lib/libc.so.6+0x3bce5)                                                                                                                                     
 #6 0x00007fa0c9115857 abort (/usr/lib/libc.so.6+0x25857)                                                                                                                                     
 #7 0x00007fa0c98aba6c bindingsErrorHandler(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) /home/dylan/projects/llvm/llvm-project/llvm/l
ib/Support/ErrorHandling.cpp:219:55                                                                                                                                                           
 #8 0x00007fa0ceda9895 llvm::AVRInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>, llvm::DebugLoc const&, llvm::MCRegister, llvm::M
CRegister, bool) const /home/dylan/projects/llvm/llvm-project/llvm/lib/Target/AVR/AVRInstrInfo.cpp:77:43                                                                                      
 #9 0x00007fa0cce3f8c2 (anonymous namespace)::ExpandPostRA::LowerCopy(llvm::MachineInstr*) /home/dylan/projects/llvm/llvm-project/llvm/lib/CodeGen/ExpandPostRAPseudos.cpp:166:19             
#10 0x00007fa0cce3fc07 (anonymous namespace)::ExpandPostRA::runOnMachineFunction(llvm::MachineFunction&) /home/dylan/projects/llvm/llvm-project/llvm/lib/CodeGen/ExpandPostRAPseudos.cpp:215:2
0

I suspect that Rust compiling LLVM in optimized mode might be hiding this error, or there is something going on that causes it to not be triggered in a normal LLVM invocation (for example, Rust configures some non-standard features of LLVM).

I have updated my local LLVM checkout to see if it has been fixed upstream (a fix for something that would cause something like this symptom recently landed in upstream LLVM), and I'm re-compiling my local Rust with LLVM optimizations disabled to see if I get the same assert as I did with standard LLVM.

[indirect]

I agree, Xargo has not kept up to date with Rust's move of Cargo.lock from rust/src folder to top-level rust folder, it cannot compile blink.

Oops, I guess I made a typo: my experience is that xargo build works while cargo xbuild does not. Possibly because the optimization flags aren’t getting forwarded to rustc by cargo xbuild?

[dylanmckay]

I wonder if it worked for you on the current avr-support branch but did not work for me due to the upstream branch having newer changes to rustc than Xargo supports. It seems to me like to move to cargo-xbuild is inevitable, as the de-facto "official "fork of Xargo

Oops, I guess I made a typo: my experience is that xargo build works while cargo xbuild does not. > Possibly because the optimization flags aren’t getting forwarded to rustc by cargo xbuild?

That sounds reasonable, although in my case I don't want to pass the explicit optimization flags because I'm trying to trigger the error :P

[dylanmckay]

I have updated my local LLVM checkout to see if it has been fixed upstream (a fix for something that would cause something like this symptom recently landed in upstream LLVM), and I'm re-compiling my local Rust with LLVM optimizations disabled to see if I get the same assert as I did with standard LLVM.

When I did this last night, it still failed.