Skip to content

RUSTFLAGS="-C target-cpu=native" causes EXC_BAD_ACCESS (code=EXC_I386_GPFLT) in nightly #48613

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rohitjoshi opened this issue Feb 28, 2018 · 10 comments
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@rohitjoshi
Copy link
Contributor

Hello,
When I use RUSTFLAGS="-C target-cpu=native cargo build --release" flag to build in the release mode, I am getting EXC_BAD_ACCESS error but if I use without this native flag, cargo build --release, it works fine.

OS:

uname -a
Darwin xxxxx_ 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64

Rust Version:

 rustc --version
rustc 1.25.0-nightly (5313e8728 2018-02-17)

Cargo Version:

cargo --version
cargo 0.24.0

Compiler Flag to reproduce error:

RUSTFLAGS="-C target-cpu=native" cargo build --release

Toml settings:

[profile.release]
lto = true
codegen-units=1

With target-cpu flag: RUSTFLAGS="-C target-cpu=native cargo build --release

RUST_BACKTRACE=1 RUST_LOG=INFO lldb ./target/release/tsp
(lldb) target create "./target/release/tsp"
Current executable set to './target/release/tsp' (x86_64).
(lldb) run
Process 19242 launched: './target/release/tsp' (x86_64)
Process 19242 stopped
* thread #2, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010014bfe7 tsp`std::sys_common::thread_info::set::hf6e9259ac1ddb2db + 119
tsp`std::sys_common::thread_info::set::hf6e9259ac1ddb2db:
->  0x10014bfe7 <+119>: vmovaps (%rax), %ymm0
    0x10014bfeb <+123>: vmovaps 0x4b8d4d(%rip), %ymm1
    0x10014bff3 <+131>: vmovaps %ymm1, (%rax)
    0x10014bff7 <+135>: vmovups %ymm0, 0x10(%rsp)
Target 0: (tsp) stopped.

Without target cpu flag: cargo build --release

RUST_BACKTRACE=1 RUST_LOG=INFO lldb ./target/release/tsp
(lldb) target create "./target/release/tsp"
Current executable set to './target/release/tsp' (x86_64).
(lldb) run
Process 21359 launched: './target/release/tsp' (x86_64)
Feb 28 11:55:21.237 INFO tsp_init...
Feb 28 11:55:21.237 INFO Initializing CacheMgr...
@rohitjoshi
Copy link
Contributor Author

NOTE: This worked fine with 1.24.0 nightly.

@michael-p
Copy link

I'm seeing a similar issue on recent nightly (1.26.0-nightly (0ff9872b2 2018-02-28)), the generated binary simply "hangs" (but with 100% CPU utilization) with target-cpu=native but works fine without. Also, Debug-builds work fine. Compilation settings are

[profile.release]
codegen-units = 1
lto = true
panic = "abort"

Possibly related: #48464

@pietroalbini
Copy link
Member

@rohitjoshi this seems like it's a duplicate of #48464, can you check if the output of rustc -C target-cpu=help (on the second line) matches your current CPU model?

@pietroalbini pietroalbini added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Mar 6, 2018
@rohitjoshi
Copy link
Contributor Author

rustc -C target-cpu=help
Available CPUs for this target:
    native         - Select the CPU of the current host (currently skylake).
    amdfam10       - Select the amdfam10 processor.
    athlon         - Select the athlon processor.
    athlon-4       - Select the athlon-4 processor.
    athlon-fx      - Select the athlon-fx processor.
    athlon-mp      - Select the athlon-mp processor.
    athlon-tbird   - Select the athlon-tbird processor.
    athlon-xp      - Select the athlon-xp processor.
    athlon64       - Select the athlon64 processor.
    athlon64-sse3  - Select the athlon64-sse3 processor.
    atom           - Select the atom processor.
    barcelona      - Select the barcelona processor.
    bdver1         - Select the bdver1 processor.
    bdver2         - Select the bdver2 processor.
    bdver3         - Select the bdver3 processor.
    bdver4         - Select the bdver4 processor.
    bonnell        - Select the bonnell processor.
    broadwell      - Select the broadwell processor.
    btver1         - Select the btver1 processor.
    btver2         - Select the btver2 processor.
    c3             - Select the c3 processor.
    c3-2           - Select the c3-2 processor.
    cannonlake     - Select the cannonlake processor.
    core-avx-i     - Select the core-avx-i processor.
    core-avx2      - Select the core-avx2 processor.
    core2          - Select the core2 processor.
    corei7         - Select the corei7 processor.
    corei7-avx     - Select the corei7-avx processor.
    generic        - Select the generic processor.
    geode          - Select the geode processor.
    goldmont       - Select the goldmont processor.
    haswell        - Select the haswell processor.
    i386           - Select the i386 processor.
    i486           - Select the i486 processor.
    i586           - Select the i586 processor.
    i686           - Select the i686 processor.
    icelake        - Select the icelake processor.
    ivybridge      - Select the ivybridge processor.
    k6             - Select the k6 processor.
    k6-2           - Select the k6-2 processor.
    k6-3           - Select the k6-3 processor.
    k8             - Select the k8 processor.
    k8-sse3        - Select the k8-sse3 processor.
    knl            - Select the knl processor.
    knm            - Select the knm processor.
    lakemont       - Select the lakemont processor.
    nehalem        - Select the nehalem processor.
    nocona         - Select the nocona processor.
    opteron        - Select the opteron processor.
    opteron-sse3   - Select the opteron-sse3 processor.
    penryn         - Select the penryn processor.
    pentium        - Select the pentium processor.
    pentium-m      - Select the pentium-m processor.
    pentium-mmx    - Select the pentium-mmx processor.
    pentium2       - Select the pentium2 processor.
    pentium3       - Select the pentium3 processor.
    pentium3m      - Select the pentium3m processor.
    pentium4       - Select the pentium4 processor.
    pentium4m      - Select the pentium4m processor.
    pentiumpro     - Select the pentiumpro processor.
    prescott       - Select the prescott processor.
    sandybridge    - Select the sandybridge processor.
    silvermont     - Select the silvermont processor.
    skx            - Select the skx processor.
    skylake        - Select the skylake processor.
    skylake-avx512 - Select the skylake-avx512 processor.
    slm            - Select the slm processor.
    westmere       - Select the westmere processor.
    winchip-c6     - Select the winchip-c6 processor.
    winchip2       - Select the winchip2 processor.
    x86-64         - Select the x86-64 processor.
    yonah          - Select the yonah processor.
    znver1         - Select the znver1 processor.

@pietroalbini
Copy link
Member

@rohitjoshi thanks! What's the CPU model you're using?

@rohitjoshi
Copy link
Contributor Author

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz

@pietroalbini
Copy link
Member

OK, this doesn't seem to be the same issue as #48464, since the recognized CPU is correct. Thanks for reporting it!

@tedhorst
Copy link
Contributor

tedhorst commented Apr 2, 2018

I am also seeing hangs on any executable compiled with both lto and -target-cpu=native.

The cpu selection appears to be correct:

rustc -C target-cpu=help
    native         - Select the CPU of the current host (currently sandybridge).

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz

The executable runs with 'core2', 'corei7', 'nehalem', and 'x86-64', but hangs with 'sandybridge', 'corei7-avx', and 'core-avx-i'.

This is on mac:

uname -a
Darwin boo-2.local 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar  5 22:24:32 PST 2018; root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64

This happened before on LLVM 5. It started between 0b17b4c and 78d8416 and was fixed by 77efd68. It started happening again on LLVM 6, sometime before 45fba43.

Executables do not always hang the first time they are run.

Sampling the hung program gives:

Call graph:
    2694 Thread_7720   DispatchQueue_1: com.apple.main-thread  (serial)
      2694 start  (in libdyld.dylib) + 1  [0x7fff6096f015]
        2694 0x0
          2694 _sigtramp  (in libsystem_platform.dylib) + 26  [0x7fff60c7df5a]
            2694 std::sys::unix::stack_overflow::imp::signal_handler::h90fb82b6c0c85c05 (.llvm.7884192080853486565)  (in deadlock) + 120  [0x108d07c78]

The call stack was similar when this was happening on LLVM 5.

@mati865
Copy link
Member

mati865 commented Aug 21, 2019

Rust is now using LLVM 9, is this still an issue?

@tedhorst
Copy link
Contributor

I haven't seen the problem since sometime before 9fd3d78 which was merged 2018-07-07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants