search

avr-rust / rust-legacy-fork

[deprecated; merged upstream] A fork of the Rust programming language with AVR support
Other
492 stars 14 forks source link

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

Open indirect opened 4 years ago

indirect commented 4 years ago

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: ::default 4: ::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 commented 4 years ago

I'm hitting this too in #155.

shepmaster commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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

Rahix commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.