rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.64k stars 12.49k forks source link

rustc --version segmentation fault #52772

Open elias36 opened 6 years ago

elias36 commented 6 years ago

After installing rust with $ curl -sSf https://static.rust-lang.org/rustup.sh | sh (following info found at https://github.com/rust-lang-nursery/rustup.rs/issues/695), a segmentation fault occurs when running rustc.

I tried the following code and received notification of the the fault instead of the version string:

$ rustc --version
Segmentation fault

When running the command via strace, the version string displays:

$ strace -o /dev/null rustc --version
rustc 1.27.2 (58cc626de 2018-07-18)

Info about the system:

$ strace -o /dev/null rustc --version --verbose
rustc 1.27.2 (58cc626de 2018-07-18)
binary: rustc
commit-hash: 58cc626de3301192d5d8c6dcbde43b5b44211ae2
commit-date: 2018-07-18
host: i686-unknown-linux-gnu
release: 1.27.2
LLVM version: 6.0

$ cat /etc/*-release
Fedora release 20 (Heisenbug)
NAME=Fedora
VERSION="20 (Heisenbug)"
ID=fedora
VERSION_ID=20
PRETTY_NAME="Fedora 20 (Heisenbug)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:20"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=20
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=20
Fedora release 20 (Heisenbug)
Fedora release 20 (Heisenbug)

$ uname --all
Linux s7netserver 3.12.5-301.fc20.i686+PAE #1 SMP Mon Dec 16 18:42:48 EST 2013 i686 i686 i386 GNU/Linux

$ lscpu
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 55
Model name:            Intel(R) Celeron(R) CPU  N2807  @ 1.58GHz
Stepping:              8
CPU MHz:               498.000
CPU max MHz:           1578.0000
CPU min MHz:           498.0000
BogoMIPS:              3166.39
Virtualization:        VT-x
L1d cache:             24K
L1i cache:             32K
L2 cache:              1024K

Backtrace:

$ RUST_BACKTRACE=1 rustc --version
Segmentation fault

gdb:

$ gdb -quiet --args rustc --version
Reading symbols from rustc...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/bin/rustc --version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.
(gdb) list
1   /* Data for i386 version of processor capability information.
2      Copyright (C) 2001-2013 Free Software Foundation, Inc.
3      This file is part of the GNU C Library.
4      Contributed by Ulrich Drepper <drepper@redhat.com>, 2001.
5   
6      The GNU C Library is free software; you can redistribute it and/or
7      modify it under the terms of the GNU Lesser General Public
8      License as published by the Free Software Foundation; either
9      version 2.1 of the License, or (at your option) any later version.
10  
(gdb)

The gdb 'edit' command leads to this being displayed:

"/usr/src/debug/glibc-2.18/sysdeps/i386/dl-procinfo.c" 82L, 2484C

Post made by me on the Rust forum in relation to this issue: https://users.rust-lang.org/t/rustc-version-segmentation-fault/19100/5?u=zis

Mark-Simulacrum commented 6 years ago

Cc @rust-lang/compiler

eddyb commented 6 years ago
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.

This part indicates that by the time bt was run, the process was already gone. Which is a bit surprising, you would think a SIGSEGV would get caught by gdb.

With the existing information I'm not sure I can provide any help.

elias36 commented 6 years ago

Thanks for the feedback. Please send any instructions for getting further information that may be useful.

eddyb commented 6 years ago

Oh if you're using rustup, then rustc would be a wrapper, and not the actual executable you need to run inside gdb, but I don't know where to find the real one. cc @alexcrichton

Mark-Simulacrum commented 6 years ago

rustup which rustc should do it.

elias36 commented 6 years ago

Thanks. rustup is not installed.

pnkfelix commented 6 years ago

Maybe set a breakpoint on main before you run, so we can at least establish if you’re even getting that far? (I’m personally wondering if this is something going wrong with dynamic library loading or linking...)

elias36 commented 6 years ago

Yep, thanks for the tip:

$ gdb -quiet --args rustc --version
Reading symbols from rustc...(no debugging symbols found)...done.
(gdb) break main
Breakpoint 1 at 0xa10
(gdb) run
Starting program: /usr/local/bin/rustc --version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, 0x80000a10 in main ()
(gdb) bt
#0  0x80000a10 in main ()
(gdb) list
1   /* Data for i386 version of processor capability information.
2      Copyright (C) 2001-2013 Free Software Foundation, Inc.
3      This file is part of the GNU C Library.
4      Contributed by Ulrich Drepper <drepper@redhat.com>, 2001.
5   
6      The GNU C Library is free software; you can redistribute it and/or
7      modify it under the terms of the GNU Lesser General Public
8      License as published by the Free Software Foundation; either
9      version 2.1 of the License, or (at your option) any later version.
10  
(gdb)
pnkfelix commented 6 years ago
  1. What about the start of the main that’s in Rust? The code for which you showed list output looks like the code for gnu libc?

  2. Does the crash still happen if you continue From such a breakpoint? (I was going to ask you to step through lines via next, but I don’t think that will be fruitful it you’re not using a local build ...

  3. Does the crash occur on a locally built rustc ?

elias36 commented 6 years ago

1 & 2: I found the rustc::main::h8593b8c0c617293e function which may relate to Rust's main function:

[root@s7netserver dev]# gdb -quiet --args rustc --version
Reading symbols from rustc...(no debugging symbols found)...done.
(gdb) break rustc::main::h8593b8c0c617293e
Breakpoint 1 at 0x9f0
(gdb) run
Starting program: /usr/local/bin/rustc --version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, 0x800009f0 in rustc::main::h8593b8c0c617293e ()
(gdb) continue
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 

2: using next:

[root@s7netserver dev]# gdb -quiet --args rustc --version
Reading symbols from rustc...(no debugging symbols found)...done.
(gdb) break rustc::main::h8593b8c0c617293e
Breakpoint 1 at 0x9f0
(gdb) run
Starting program: /usr/local/bin/rustc --version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Breakpoint 1, 0x800009f0 in rustc::main::h8593b8c0c617293e ()
(gdb) next
Single stepping until exit from function _ZN5rustc4main17h8593b8c0c617293eE,
which has no line number information.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 

3: A segmentation fault occurs when trying to build rustc. Note that cmake is version 2.8.12.2 instead of the specified 3.4.3 or later, and git is not used:

[root@s7netserver rustc-1.27.2-src]# ./x.py build && sudo ./x.py install
      <output deleted>
failed to run: /root/dev/rust/rustc-1.27.2-src/build/i686-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /root/dev/rust/rustc-1.27.2-src/src/bootstrap/Cargo.toml
Build completed unsuccessfully in 0:01:06
[root@s7netserver rustc-1.27.2-src]# /root/dev/rust/rustc-1.27.2-src/build/i686-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /root/dev/rust/rustc-1.27.2-src/src/bootstrap/Cargo.toml
Segmentation fault

I got this output from gdb about the functions it comes across:

[root@s7netserver dev]# gdb -quiet --args rustc --version
Reading symbols from rustc...(no debugging symbols found)...done.
(gdb) rbreak .
    <output deleted>
(gdb) commands
Type commands for breakpoint(s) 1-31, one per line.
End with a line saying just "end".
>continue
>end
(gdb) run
Starting program: /usr/local/bin/rustc --version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

    <output deleted>

---Type <return> to continue, or q <return> to quit---
Breakpoint 4, 0x800007a0 in __rde_alloc@plt ()

Breakpoint 24, 0x80000a50 in __rust_alloc ()

Breakpoint 4, 0x800007a0 in __rde_alloc@plt ()

Breakpoint 24, 0x80000a50 in __rust_alloc ()

Breakpoint 4, 0x800007a0 in __rde_alloc@plt ()

Breakpoint 24, 0x80000a50 in __rust_alloc ()

Breakpoint 4, 0x800007a0 in __rde_alloc@plt ()

Breakpoint 24, 0x80000a50 in __rust_alloc ()

Breakpoint 4, 0x800007a0 in __rde_alloc@plt ()

Breakpoint 26, 0x80000ab0 in __rust_realloc ()

Breakpoint 6, 0x800007c0 in __rde_realloc@plt ()

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 
workingjubilee commented 1 year ago

https://github.com/rust-lang/rust/issues/73527 makes me wonder if there's some random codegen problem in LLVM for i686 that rustc sometimes hits...