Skip to content

SIGSEGV compiling num-integer for asmjs-unknown-emscripten #66308

New issue
New issue
Closed
#68525
Closed
SIGSEGV compiling num-integer for asmjs-unknown-emscripten#66308
#68525
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-asmjsTarget: asm.js - http://asmjs.org/O-emscriptenTarget: 50% off wasm32-unknown-musl. the savings come out of stdio.h, but hey, you get SDL!P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Description

@cuviper
cuviper
opened on Nov 11, 2019

On current num-integer master (commit f0e329af1195), rustc nightly and beta both crash when targeting asmjs-unknown-emscripten. Stable is fine.

   stable-x86_64-unknown-linux-gnu - rustc 1.39.0 (4560ea788 2019-11-04)
     beta-x86_64-unknown-linux-gnu - rustc 1.40.0-beta.1 (76b40532a 2019-11-05)
  nightly-x86_64-unknown-linux-gnu - rustc 1.40.0-nightly (3fc30d884 2019-11-10)

$ cargo +stable build --target asmjs-unknown-emscripten
   Compiling autocfg v0.1.7
   Compiling num-traits v0.2.8
   Compiling num-integer v0.1.41 (/home/jistone/rust/num/integer)
    Finished dev [unoptimized + debuginfo] target(s) in 2.60s

$ cargo +beta build --target asmjs-unknown-emscripten
   Compiling num-integer v0.1.41 (/home/jistone/rust/num/integer)
warning: `#[inline]` is ignored on function prototypes
   --> src/lib.rs:260:5
    |
260 |     #[inline]
    |     ^^^^^^^^^
    |
    = note: `#[warn(unused_attributes)]` on by default

Referencing function in another module!
  call void <badref>(i8* %40), !dbg !50
; ModuleID = '39eosbi6n9pwhhcp'
void (i8*)* <badref>
; ModuleID = '
error: could not compile `num-integer`.

Caused by:
  process didn't exit successfully: `rustc --crate-name num_integer src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=795c310a63594098 -C extra-filename=-795c310a63594098 --out-dir /home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps --target asmjs-unknown-emscripten -C incremental=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/incremental -L dependency=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps -L dependency=/home/jistone/rust/num/integer/target/debug/deps --extern num_traits=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps/libnum_traits-2f98a4660a35fd13.rmeta --cfg has_i128` (signal: 11, SIGSEGV: invalid memory reference)

$ cargo +nightly build --target asmjs-unknown-emscripten
   Compiling num-integer v0.1.41 (/home/jistone/rust/num/integer)
warning: `#[inline]` is ignored on function prototypes
   --> src/lib.rs:260:5
    |
260 |     #[inline]
    |     ^^^^^^^^^
    |
    = note: `#[warn(unused_attributes)]` on by default

Referencing function in another module!
  call void <badref>(i8* %40), !dbg !50
; ModuleID = '4z4jvx7urdbbg8j3'
void (i8*)* <badref>
; ModuleID = '
error: could not compile `num-integer`.

Caused by:
  process didn't exit successfully: `rustc --crate-name num_integer src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=947cae8a7fd914b6 -C extra-filename=-947cae8a7fd914b6 --out-dir /home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps --target asmjs-unknown-emscripten -C incremental=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/incremental -L dependency=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps -L dependency=/home/jistone/rust/num/integer/target/debug/deps --extern num_traits=/home/jistone/rust/num/integer/target/asmjs-unknown-emscripten/debug/deps/libnum_traits-1f95a1b3834a3c5f.rmeta --cfg has_i128` (signal: 11, SIGSEGV: invalid memory reference)

(The inline attribute warning is irrelevant to success/failure, but I'll clean that up separately.)

cc @mashedcode rust-num/num-integer#28

Activity

  1. cuviper
    added
    I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    O-asmjsTarget: asm.js - http://asmjs.org/
    on Nov 11, 2019

  2. cuviper commented on Nov 11, 2019

    @cuviper
    cuviper
    on Nov 11, 2019
    MemberAuthor
    GDB backtrace of the SIGSEGV thread on nightly: 
    (gdb) bt
#0  0x00007fffeee66962 in void llvm::VerifierSupport::WriteTs<llvm::Function*, llvm::Module*>(llvm::Function* const&, llvm::Module* const&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#1  0x00007fffeee70d93 in (anonymous namespace)::Verifier::visitInstruction(llvm::Instruction&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#2  0x00007fffeee7d93c in (anonymous namespace)::Verifier::visitCallInst(llvm::CallInst&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#3  0x00007fffeee584e8 in (anonymous namespace)::Verifier::verify(llvm::Function const&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#4  0x00007fffeee7eff3 in (anonymous namespace)::VerifierLegacyPass::runOnFunction(llvm::Function&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#5  0x00007fffeee0242f in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#6  0x00007fffeee02893 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#7  0x00007fffeee03030 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-9-rust-1.40.0-nightly.so
#8  0x00007ffff18791bf in LLVMRustWriteOutputFile ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#9  0x00007ffff182478c in rustc_codegen_llvm::back::write::write_output_file ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#10 0x00007ffff17179e6 in rustc_codegen_llvm::back::write::codegen::{{closure}} ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#11 0x00007ffff17139f1 in rustc::util::common::time_ext ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#12 0x00007ffff1834221 in <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::write::WriteBackendMethods>::codegen ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#13 0x00007ffff174a294 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#14 0x00007ffff174bcb6 in std::panicking::try::do_call ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#15 0x00007ffff511eeea in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:79
#16 0x00007ffff1726706 in core::ops::function::FnOnce::call_once{{vtable-shim}} ()
   from /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
#17 0x00007ffff50efc8f in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once ()
    at /rustc/3fc30d884ae0c988d98452a06737705cfe34806a/src/liballoc/boxed.rs:942
#18 0x00007ffff511d910 in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once ()
    at /rustc/3fc30d884ae0c988d98452a06737705cfe34806a/src/liballoc/boxed.rs:942
#19 std::sys_common::thread::start_thread () at src/libstd/sys_common/thread.rs:13
#20 std::sys::unix::thread::Thread::new::thread_start () at src/libstd/sys/unix/thread.rs:79
#21 0x00007ffff505d4e2 in start_thread () from /lib64/libpthread.so.0
#22 0x00007ffff4f7a643 in clone () from /lib64/libc.so.6
  3. jonas-schievink
    added
    C-bugCategory: This is a bug.
    on Nov 11, 2019

  4. mashedcode commented on Nov 11, 2019

    @mashedcode
    mashedcode
    on Nov 11, 2019

    Thanks @cuviper. Minimal reproducible test case:

    pub fn foo() {
    (0..0).rev().next();
}

  5. pnkfelix commented on Nov 14, 2019

    @pnkfelix
    pnkfelix
    on Nov 14, 2019
    Contributor

    triage: P-high for now. (but this is a Tier-2 target, so it may get downgraded to P-medium after a few weeks. We will see.)

  6. pnkfelix
    added
    P-highHigh priority
    on Nov 14, 2019

  7. cuviper commented on Nov 14, 2019

    @cuviper
    cuviper
    on Nov 14, 2019
    MemberAuthor

    cc #65251 @tlively @alexcrichton -- the versions correspond to the LLVM change for emscripten.

  8. tlively commented on Nov 14, 2019

    @tlively
    tlively
    on Nov 14, 2019
    Contributor

    This looks like an error in the LLVM verifier, so there is something wrong with the generated LLVM IR. I think we can rule out a bug in the WebAssembly LLVM backend.

  9. alexcrichton commented on Nov 15, 2019

    @alexcrichton
    alexcrichton
    on Nov 15, 2019
    Member

    Sorry I'm not sure where this would be coming from either.. It's likely due to the upgrade of LLVM for the emscripten target for sure though

  10. kubkon
    added 2 commits that reference this issue on Dec 20, 2019

    Disable Emscripten job

    54eaf55

    Disable Emscripten job

    a582389

  11. 7 remaining items

  12. tlively commented on Jan 6, 2020

    @tlively
    tlively
    on Jan 6, 2020
    Contributor

    It looks like this is a use-after-free when LLVM is built in release mode. It is caught earlier by an assertion with a debug build of LLVM, and from the backtrace there it looks like there is indeed a previously-unknown issue with the Emscripten exception lowering pass. We are investigating further now.

  13. tlively commented on Jan 7, 2020

    @tlively
    tlively
    on Jan 7, 2020
    Contributor

    Fix in LLVM incoming: https://reviews.llvm.org/D72308. Once it merges upstream, I will handle getting it merged to Rust's LLVM fork and from there to rustc.

  14. bors
    added 2 commits that reference this issue on Jan 18, 2020

    Update LLVM to fix crash on Emscripten targets

    914befe

  15. tmandry commented on Jan 21, 2020

    @tmandry
    tmandry
    on Jan 21, 2020
    Member

    Should be fixed by #68030.

  16. tmandry
    closed this as completedon Jan 21, 2020

  17. cuviper commented on Jan 21, 2020

    @cuviper
    cuviper
    on Jan 21, 2020
    MemberAuthor

    Were you able to verify that? I can still reproduce it with rustc 1.42.0-nightly (b5a3341f1 2020-01-20).

  18. tmandry commented on Jan 21, 2020

    @tmandry
    tmandry
    on Jan 21, 2020
    Member

    No, I just checked that the patch had landed. Reopening.

  19. tmandry
    reopened this on Jan 21, 2020

  20. tlively commented on Jan 23, 2020

    @tlively
    tlively
    on Jan 23, 2020
    Contributor

    I thought it had been fixed because the regression test I had locally for it passes. But it turns out the test runner uses -C opt-level=2 by default and the crash now needs -C opt-level=0 to be triggered. I will continue looking into this.

  21. tlively
    added a commit that references this issue on Jan 24, 2020

    Update LLVM to fix crash on Emscripten targets

    7b49c7d
  22. bors
    added a commit that references this issue on Jan 25, 2020

    Auto merge of #68525 - tlively:emcc-codegen-sigsegv-66308, r=alexcric…

    8ad83af
  23. bors
    closed this as completedin 8ad83afon Jan 25, 2020

  24. cuviper commented on Jan 26, 2020

    @cuviper
    cuviper
    on Jan 26, 2020
    MemberAuthor

    Confirmed, thanks!

  25. workingjubilee
    added
    O-emscriptenTarget: 50% off wasm32-unknown-musl. the savings come out of stdio.h, but hey, you get SDL!
    on Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-asmjsTarget: asm.js - http://asmjs.org/O-emscriptenTarget: 50% off wasm32-unknown-musl. the savings come out of stdio.h, but hey, you get SDL!P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions