cargo segmentation fault on NextThing Chip for armv7 toolchain

[chrisballinger]

stable-arm-unknown-linux-gnueabihf
stable-armv7-unknown-linux-gnueabihf

I installed both toolchains on the NextThing Chip with rustup. To my knowledge the Chip runs an Allwinner R8 and works with armv7.

With the armv7 Rust toolchain, rustc works fine, but cargo exits with a segmentation fault even when launched with no options. When I installed the arm toolchain, both rustc and cargo work as expected.

I tried to gather more information about why cargo was failing, but couldn't figure it out.

[alexcrichton]

Thanks for the report! Do you know if your chip has NEON support? That's been disabled recently in armv7 linux but I'm not sure if it's reached stable yet. Also, if you use gdb you can likely pinpoint where the binary is dying perhaps?

[chrisballinger]

The Allwinner A8 supposedly supports NEON. My Chip is running Debian 8 w/ kernel 4.4.11. https://bbs.nextthing.co/t/chip-os-4-4-released-vga-hdmi-and-more/4319

Can you give me a little guidance on how to print what you need with gdb? Thanks!

[alexcrichton]

Oh sure yeah, if you do:

gdb --args `rustup which cargo` build

that'll give you a prompt, then type run to run Cargo and it should go until it breaks.

[chrisballinger]

This the output:

Program received signal SIGSEGV, Segmentation fault.
_dl_relocate_object (scope=0xb6fffb10, reloc_mode=1, 
    consider_profiling=consider_profiling@entry=0) at dl-reloc.c:238
238	dl-reloc.c: No such file or directory.

[alexcrichton]

Interesting! Can you gist the full backtrace, and also the output of ldd --version?

[chrisballinger]

$ ldd --version
ldd (Debian GLIBC 2.19-18+deb8u6) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

$ gdb --args `rustup which cargo` build
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/xxx/.multirust/toolchains/stable-armv7-unknown-linux-gnueabihf/bin/cargo...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/xxx/.multirust/toolchains/stable-armv7-unknown-linux-gnueabihf/bin/cargo build

Program received signal SIGSEGV, Segmentation fault.
_dl_relocate_object (scope=0xb6fffb10, reloc_mode=1, 
    consider_profiling=consider_profiling@entry=0) at dl-reloc.c:238
238	dl-reloc.c: No such file or directory.

[alexcrichton]

Weird. Looks like you're using glibc 2.19 (from ldd --version) which is compatible with the binaries that we're shipping which are built against glibc 2.16, so at least that vector of segfaults is ruled out.

Other than that I'm kinda at a loss for what's happening here. @japaric do you have thoughts on perhaps how to debug this?

[japaric]

Some ideas:

• Try other releases channels to check if this is due to some code generation on our side. e.g. rustup default nightly

• Check if the CPU actually supports NEON. cat /proc/cpuinfo | grep flags

• Check if this due to the low memory of the device (512 MB). Is swap enabled? What does free -m say? Try clearing as much memory as possible before running the Cargo command.

[japaric]

Seemingly related issue: rust-lang/rustup#838 - Rustup-init 0.6.5 for ARMv7 causes segmentation fault

Over there, they claim that patchelf --add-needed /lib/ld-linux-armhf.so.3 cargo fixes the issue. Could you try that, @chrisballinger?

[chrisballinger]

• nightly-armv7-unknown-linux-gnueabihf works:

$ rustup show
Default host: armv7-unknown-linux-gnueabihf

installed toolchains
--------------------

stable-arm-unknown-linux-gnueabihf
stable-armv7-unknown-linux-gnueabihf
nightly-armv7-unknown-linux-gnueabihf (default)

active toolchain
----------------

nightly-armv7-unknown-linux-gnueabihf (default)
rustc 1.15.0-nightly (c80c31a50 2016-12-02)

$ cargo --version
cargo 0.16.0-nightly (3568be9 2016-11-26)

• cpuinfo:

$ cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 429.72
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: Allwinner sun4i/sun5i Families
Revision	: 0000
Serial		: 1625420a02420120

• free memory

$ free -m
             total       used       free     shared    buffers     cached
Mem:           491        283        208          6          0        227
-/+ buffers/cache:         55        436
Swap:            0          0          0

• couldn't figure out how to install patchelf

$ sudo apt-get install patchelf
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package patchelf

[japaric]

couldn't figure out how to install patchelf

You can grab the source from here and build it using ./configure && make.

[thegecko]

I had no problem running rust and cargo natively on the CHIP by simply installing build-essential and rustup.

[chrisballinger]

I'm pretty sure the old stable package was broken, and whatever was wrong was fixed in the nightlies. I don't have my CHIP handy to verify though.

[carols10cents]

It sounds like this has been fixed, so I'm closing. Please reopen if I'm mistaken! Thank you!