CODEWITHSUNDEEP
rustrust-cargo
Grigoriy
Grigoriy

Reputation: 51

libwasm_bindgen-a2e136f9a24e6618.rlib hangs and doesn't consume CPU when compiling

I have started learning wasm-bindgen recently. And even with first example, js-hello-world, there was a weird problem. https://github.com/rust-lang-nursery/rust-wasm

I did as was written, set rustc to nightly, then:

rustup target add wasm32-unknown-unknown
cargo install wasm-bindgen-cli
cargo new js-hello-world --lib

This is Cargo.toml:

[package]
name = "js-hello-world"
version = "0.1.0"
authors = ["[email protected]"]

[dependencies]
wasm-bindgen = "0.2.1"

[lib]
crate-type = ["cdylib"]

And lib.rs:

#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

Now when I build:

cargo build --target=wasm32-unknown-unknown -vv

Compilation actually hangs not consuming even cpu resources:

   Fresh unicode-xid v0.1.0
   Fresh serde v1.0.37
   Fresh fnv v1.0.6
   Fresh num-traits v0.2.2
   Fresh dtoa v0.4.2
   Fresh itoa v0.4.1
   Fresh proc-macro2 v0.3.6
   Fresh serde_json v1.0.13
   Fresh quote v0.5.1
   Fresh syn v0.13.1
   Fresh serde_derive_internals v0.23.0
   Fresh serde_derive v1.0.37
   Fresh wasm-bindgen-shared v0.2.1
   Fresh wasm-bindgen-backend v0.2.1
   Fresh wasm-bindgen-macro v0.2.1
   Fresh wasm-bindgen v0.2.1
   Compiling js-hello-world v0.1.0 (file:///home/markelovg/container/js-hello-world)
 Running `rustc --crate-name js_hello_world src/lib.rs --crate-type cdylib --emit=dep-info,link -C debuginfo=2 -C metadata=a4ec1c36c55eb3a5 --out-dir /home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps --target wasm32-unknown-unknown -C incremental=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/incremental -L dependency=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps -L dependency=/home/markelovg/container/js-hello-world/target/debug/deps --extern wasm_bindgen=/home/markelovg/container/js-hello-world/target/wasm32-unknown-unknown/debug/deps/libwasm_bindgen-a2e136f9a24e6618.rlib`

This libwasm_bingden-a2e136f9a24e6618.rlib dependency exists in my project but nothing then happens. How to resolve this issue?

I also tried to use gdb for lld process and this is the output:

    (gdb) bt
    #0 0xb7753cf9 in __kernel_vsyscall ()
    #1 0xb7727800 in futex_wait_cancelable (private=, expected=0, futex_word=0xbf817dac) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
    #2 __pthread_cond_wait_common (abstime=0x0, mutex=0xbf817d6c, cond=0xbf817d84) at pthread_cond_wait.c:502
    #3 __pthread_cond_wait (cond=0xbf817d84, mutex=0xbf817d6c) at pthread_cond_wait.c:655
    #4 0x09dec825 in __gthread_cond_wait (__mutex=, __cond=0xbf817d84)
    at /tmp/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:864
    #5 std::condition_variable::wait (this=0xbf817d84, __lock=...) at ../../../../../../gcc-4.8.5/libstdc++-v3/src/c++11/condition_variable.cc:52
    #6 0x08308ce9 in lld::wasm::writeResult() ()
    #7 0x082f8580 in (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) [clone .constprop.291] ()
    #8 0x082f8cbc in lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) ()
    #9 0x08093078 in main ()

Can somebody clarify to me why it waits in __kernel_vsyscall() ?

Upvotes: 1

Views: 147

Answers (2)

Grigoriy
Grigoriy

Reputation: 51

Recently tried to build this example on x86-64 linux-gnu os and it passed.So the problem has the angle with weak support for 32bit platforms from wasm-bindgen itself.Thanks

Upvotes: 0

attdona
attdona

Reputation: 18943

A process waits in __kernel_vsyscall() when there is a blocked system call.

I'm not able to say why in this particular case: I've done a quick test on my machine with your recipe and it works.

Looking at the logs it seems that you have a 64 bit target (x86_64-unknown-linux-gnu) but from the comments it seems you use a toolchain for i686 cpu.

Verify that the toolchain is nightly-x86_64-unknown-linux-gnu.

Upvotes: 1

Related Questions