wasm-pack
wasm-pack copied to clipboard
rustwasm
65214 segmentation fault (core dumped) wasm-pack help
🐛 Bug description
I run wasm-pack help and it crashes (sometimes).
wasm-pack 0.9.1
Ashley Williams <[email protected]>
📦 ✨ pack and publish your wasm!
USAGE:
wasm-pack [FLAGS] [OPTIONS] <SUBCOMMAND>
FLAGS:
-h, --help Prints help information
-q, --quiet No output printed to stdout
-V, --version Prints version information
-v, --verbose Log verbosity is based off the number of v used
OPTIONS:
--log-level <log_level> The maximum level of messages that should be logged by wasm-pack. [possible values:
info, warn, error] [default: info]
SUBCOMMANDS:
build 🏗️ build your npm package!
help Prints this message or the help of the given subcommand(s)
login 👤 Add an npm registry user account! (aliases: adduser, add-user)
new 🐑 create a new project with a template
pack 🍱 create a tar of your npm package but don't publish!
publish 🎆 pack up your npm package and publish!
test 👩🔬 test your wasm!
malloc_consolidate(): invalid chunk size
[1] 65214 segmentation fault (core dumped) wasm-pack help
🤔 Expected Behavior
Run without crash
👟 Steps to reproduce
cargo +stable install wasm-pack
wasm-pack help
🌍 Your environment
wasm-pack version: 0.9.1 rustc version: 1.42.0
I'm getting this, too. I installed the prebuilt binary, on Fedora 32.
Interestingly, if I run it with RUST_BACKTRACE=1, the segfault goes away. If I run it in gdb, I get this:
awatts@ironic-mullet ~ $ gdb $(which wasm-pack)
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 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 "x86_64-redhat-linux-gnu".
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/awatts/.cargo/bin/wasm-pack...
(gdb) run --help
Starting program: /home/awatts/.cargo/bin/wasm-pack --help
[New LWP 78640]
wasm-pack 0.9.1
Ashley Williams <[email protected]>
📦 ✨ pack and publish your wasm!
USAGE:
wasm-pack [FLAGS] [OPTIONS] <SUBCOMMAND>
FLAGS:
-h, --help Prints help information
-q, --quiet No output printed to stdout
-V, --version Prints version information
-v, --verbose Log verbosity is based off the number of v used
OPTIONS:
--log-level <log_level> The maximum level of messages that should be logged by wasm-pack. [possible values:
info, warn, error] [default: info]
SUBCOMMANDS:
build 🏗️ build your npm package!
help Prints this message or the help of the given subcommand(s)
login 👤 Add an npm registry user account! (aliases: adduser, add-user)
new 🐑 create a new project with a template
pack 🍱 create a tar of your npm package but don't publish!
publish 🎆 pack up your npm package and publish!
test 👩🔬 test your wasm!
Thread 1 "wasm-pack" received signal SIGSEGV, Segmentation fault.
0x00000000009bb64b in __bin_chunk ()
(gdb) bt
#0 0x00000000009bb64b in __bin_chunk ()
#1 0x0000000000ee6950 in ?? ()
#2 0x000000000000ddc0 in ?? ()
#3 0x0000000000000036 in ?? ()
#4 0x0000000000000060 in ?? ()
#5 0x0000000000000510 in ?? ()
#6 0x0000003600000000 in ?? ()
#7 0x0000000000000003 in ?? ()
#8 0x0000000000ee4050 in mal ()
#9 0x0000000000000080 in ?? ()
#10 0x0000000000eee020 in ?? ()
#11 0x000000000098a750 in ?? () at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/slice/mod.rs:2857
#12 0x00007fffffffcea0 in ?? ()
#13 0x00007fffffffc4d8 in ?? ()
#14 0x00000000007528e5 in OPENSSL_LH_free ()
#15 0x000000000073ab0d in err_cleanup ()
#16 0x0000000000750aa1 in OPENSSL_cleanup ()
#17 0x00000000009ba858 in __funcs_on_exit ()
#18 0x0000000000000000 in ?? ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 78636] will be killed.
Quit anyway? (y or n) y
I realize that stack trace is not super helpful.
Also, I just tried it again with no changes and now it's not segfaulting, so it appears to be an intermittent error.
This is really weird, I've never seen this before. Maybe you were running low on RAM or disk space and that's why it crashed?
Me, too. RUST_BACKTRACE=1 didn't help. RAM and the disk were free.
According to the backtrace bellow, a thread was calling ERR_load_strings_const() while the program was exiting. That function accessed a global object (err_string_lock) which was being destroyed or had already been destroyed (by OPENSSL_cleanup(), it was registered to be called by exit() by atexit()). I believe this is the reason.
Backtrace
thread #1, name = 'wasm-pack'
frame #0: 0x00007ffff7fe1abf ld-2.31.so`.annobin_dl_fini.c + 255
frame #1: 0x00007ffff79f33d7 libc.so.6`.annobin_exit.c + 247
frame #2: 0x00007ffff79f3580 libc.so.6`exit + 32
frame #3: 0x0000555555b9eb67 wasm-pack`std::sys::unix::os::exit::h6eb9114244f31004 at os.rs:605:14
frame #4: 0x0000555555b95d6f wasm-pack`std::process::exit::he2412758ae21d38b at process.rs:1562:5
frame #5: 0x0000555555a8a8df wasm-pack`clap::app::App::get_matches_from::_$u7b$$u7b$closure$u7d$$u7d$::hab942e53b3bcb4a3 + 879
frame #6: 0x0000555555a8a529 wasm-pack`clap::app::App::get_matches::hdd97dc0605dd8aab + 409
frame #7: 0x00005555557d66d7 wasm-pack`wasm_pack::main::h7bf7c0c2edc27a93 + 3191
frame #8: 0x00005555557d2333 wasm-pack`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::habfc61eae7eb3c19 + 3
frame #9: 0x0000555555b9ab68 wasm-pack`std::rt::lang_start_internal::hf4abd869024c3270 [inlined] std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hcf986077e2da8d6b at rt.rs:52:13
frame #10: 0x0000555555b9ab5d wasm-pack`std::rt::lang_start_internal::hf4abd869024c3270 [inlined] std::panicking::try::do_call::h076edd10f2a91969 at panicking.rs:297
frame #11: 0x0000555555b9ab5d wasm-pack`std::rt::lang_start_internal::hf4abd869024c3270 [inlined] std::panicking::try::h54343dd1a9d830aa at panicking.rs:274
frame #12: 0x0000555555b9ab5d wasm-pack`std::rt::lang_start_internal::hf4abd869024c3270 [inlined] std::panic::catch_unwind::h81799eb8afacafdd at panic.rs:394
frame #13: 0x0000555555b9ab5d wasm-pack`std::rt::lang_start_internal::hf4abd869024c3270 at rt.rs:51
frame #14: 0x00005555557d7072 wasm-pack`main + 34
frame #15: 0x00007ffff79db042 libc.so.6`__libc_start_main + 242
frame #16: 0x00005555557cf44e wasm-pack`_start + 46
* thread #2, name = 'wasm-pack', stop reason = signal SIGSEGV: invalid address (fault address: 0x18)
* frame #0: 0x00007ffff799868e libpthread.so.0`__pthread_rwlock_unlock + 14
frame #1: 0x00007ffff7e1a89d libcrypto.so.1.1`CRYPTO_THREAD_unlock + 13
frame #2: 0x00007ffff7d82495 libcrypto.so.1.1`ERR_load_strings_const + 85
frame #3: 0x00007ffff7d99564 libcrypto.so.1.1`ERR_load_EVP_strings + 52
frame #4: 0x00007ffff7d837a0 libcrypto.so.1.1`err_load_crypto_strings_int + 64
frame #5: 0x00007ffff7dab1dd libcrypto.so.1.1`ossl_init_load_crypto_strings_ossl_ + 13
frame #6: 0x00007ffff799aacf libpthread.so.0`.annobin_pthread_setcanceltype.c_end + 191
frame #7: 0x00007ffff7e1a8fd libcrypto.so.1.1`CRYPTO_THREAD_run_once + 13
frame #8: 0x00007ffff7dab71b libcrypto.so.1.1`OPENSSL_init_crypto + 491
frame #9: 0x00007ffff7d82ae6 libcrypto.so.1.1`ERR_get_state + 246
frame #10: 0x00007ffff7d82c1d libcrypto.so.1.1`ERR_clear_error + 13
frame #11: 0x00007ffff7dab0ed libcrypto.so.1.1`ossl_init_engine_rdrand_ossl_ + 13
frame #12: 0x00007ffff799aacf libpthread.so.0`.annobin_pthread_setcanceltype.c_end + 191
frame #13: 0x00007ffff7e1a8fd libcrypto.so.1.1`CRYPTO_THREAD_run_once + 13
frame #14: 0x00007ffff7dab8ed libcrypto.so.1.1`OPENSSL_init_crypto + 957
frame #15: 0x00007ffff7be7365 libcurl.so.4`Curl_ossl_init + 21
frame #16: 0x00007ffff7baf8e4 libcurl.so.4`global_init.part.0 + 84
frame #17: 0x0000555555a2d41a wasm-pack`std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::h76a301350f818854 + 26
frame #18: 0x0000555555b9678b wasm-pack`std::sync::once::Once::call_inner::hb7f6320e166dc07b at once.rs:416:21
frame #19: 0x0000555555a2e1c0 wasm-pack`curl::init::hab6efe0f8eeb6aab + 64
frame #20: 0x0000555555841e25 wasm-pack`curl::easy::handler::Easy2$LT$H$GT$::new::h92fea0c2720a273d + 21
frame #21: 0x000055555586c5ac wasm-pack`wasm_pack::manifest::Crate::return_api_call_result::hed7ece7b1ab9670e + 76
frame #22: 0x000055555586c2c1 wasm-pack`wasm_pack::manifest::Crate::return_wasm_pack_latest_version::h04e6ec39cedd00ff + 353
frame #23: 0x0000555555827366 wasm-pack`wasm_pack::build::check_wasm_pack_versions::hf3649c403f85d039 + 166
frame #24: 0x00005555557d90df wasm-pack`std::sys_common::backtrace::__rust_begin_short_backtrace::hb32ca9c2e4ef7092 + 31
frame #25: 0x00005555557d264e wasm-pack`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hcd39e8ee8620d7f3 + 78
frame #26: 0x0000555555ba391a wasm-pack`std::sys::unix::thread::Thread::new::thread_start::h62c1349f59256f0d [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h54527dd7ea0101d8 at boxed.rs:1076:9
frame #27: 0x0000555555ba3914 wasm-pack`std::sys::unix::thread::Thread::new::thread_start::h62c1349f59256f0d [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h731fd1bfc62ba945 at boxed.rs:1076
frame #28: 0x0000555555ba390b wasm-pack`std::sys::unix::thread::Thread::new::thread_start::h62c1349f59256f0d at thread.rs:87
frame #29: 0x00007ffff7992432 libpthread.so.0`start_thread + 226
frame #30: 0x00007ffff7ab59d3 libc.so.6`__clone + 67
alexcrichton/curl-rust#333 is related to this, as the backtrace shows the second thread was calling curl::init(). I sometimes got a double free error, too. alexcrichton/curl-rust#334 has fixed that issue. That fix is included in curl-rust 0.4.30. Updating it may solve this issue.
Edit: I'm not getting this anymore after updating curl to 0.4.30. ~~I believe it will fix this issue.~~ I believe it will fix this issue partially, as sfackler/rust-openssl#1293 (openssl/openssl#6214) can also lead to segfault.
sfackler/rust-openssl#1324 has been merged (but not released) now and we should update openssl (by using [patch.crates-io]?) instead.
I just installed rustup and wasm-pack and tried to run a hello world example and got a segmentation fault. wasm-pack version: 0.10.1 rust version: 1.56.1
GNU gdb (GDB) 11.1
Copyright (C) 2021 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 "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 wasm-pack...
(gdb) run build
Starting program: /home/yoga/.cargo/bin/wasm-pack build
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff7302640 (LWP 17180)]
[New Thread 0x7ffff7101640 (LWP 17182)]
[Detaching after vfork from child process 17181]
warning: Corrupted shared library list: 0x7ffff732b100 != 0x7fffe80010f0
[Detaching after vfork from child process 17183]
[INFO]: Checking for the Wasm target...
[Detaching after vfork from child process 17184]
[INFO]: Compiling to Wasm...
[Detaching after vfork from child process 17186]
[Thread 0x7ffff7101640 (LWP 17182) exited]
Finished release [optimized] target(s) in 0.00s
[WARN]: :-) origin crate has no README
[INFO]: Installing wasm-bindgen...
[New Thread 0x7ffff7101640 (LWP 17188)]
[Thread 0x7ffff7101640 (LWP 17188) exited]
Thread 2 "wasm-pack" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7302640 (LWP 17180)]
0x00007ffff7aa32c3 in SSL_get_peer_certificate () from /usr/lib/libssl.so.1.1
Running RUST_BACKTRACE=1 wasm-pack build doesn't give any more info.
I am having the same issue, but only when building in a docker file. Running directly on my Computer it works fine.
The Dockerfile:
FROM rust:1
WORKDIR /opt
COPY my-folder .
RUN cargo install wasm-pack
RUN wasm-pack build
I first thought this might be caused by a newer rustc inside the docker, but both rustc and wasm-pack seem to be the same version:
Step 5/18 : RUN rustc --version
---> Running in c494bdd3da53
rustc 1.55.0 (c8dfcfe04 2021-09-06)
Removing intermediate container c494bdd3da53
---> 975680e06f36
Step 6/18 : RUN wasm-pack --version
---> Running in 15f2de23f1f5
wasm-pack 0.10.1
Removing intermediate container 15f2de23f1f5
Any ideas on how to fix this? adding RUST_BACKTRACE=1 has no effect.
EDIT: I tried using different versions of rustc (i.e. different version of the rust docker image), but none worked (1.54, 1.56, bullseye/buster, ...). I also tried installing wasm-pack directly from git using cargo install --git https://github.com/rustwasm/wasm-pack, but no luck either.
I am out of ideas at this point, especially as it used to work a few days ago
Same issue here. I even tried to do the Wasm tutorial juste to be sure it wasn't just my project.
But when I build with wasm-pack build --target web I get :
[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
Compiling demo v0.1.0 (/home/marius/Projects/Wasm/demo)
Finished release [optimized] target(s) in 0.12s
[1] 33739 segmentation fault (core dumped) RUST_BACKTRACE=1 wasm-pack build --target web
I thought it was because of Rust 2021 but I tried with 2018 and got the same result.
I saw this thread was active some days ago but it seems no one find a suitable solution.
EDIT: I tried once more and got an even weirder result
[marius:~/Projects/Wasm/demo]$ RUST_BACKTRACE=1 wasm-pack build --target web (master✱)
[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
[1] 35367 segmentation fault (core dumped) RUST_BACKTRACE=1 wasm-pack build --target web
[marius:~/Projects/Wasm/demo]$ Compiling proc-macro2 v1.0.32 (master✱)
Compiling unicode-xid v0.2.2
Compiling log v0.4.14
Compiling wasm-bindgen-shared v0.2.78
Compiling syn v1.0.81
Compiling cfg-if v1.0.0
Compiling lazy_static v1.4.0
Compiling bumpalo v3.8.0
Compiling wasm-bindgen v0.2.78
Compiling quote v1.0.10
Compiling wasm-bindgen-backend v0.2.78
Compiling wasm-bindgen-macro-support v0.2.78
Compiling wasm-bindgen-macro v0.2.78
Compiling demo v0.1.0 (/home/marius/Projects/Wasm/demo)
Finished release [optimized] target(s) in 4.91s
It segfaulted and gave me back control of my shell but "started building" nonetheless. ./pkg/ folder was still empty tho...
As I couldn't find a workaround, I fiddled a bit with it myself. In the end, I ended up changing the curl dependency to use static-curl, which seems to be solving this issue (sadly, this cannot be done via patch, as that doesn't support changing features):
-curl = "0.4.13"
+curl = { version = "0.4.13", features = ['static-curl'] }
In Config.toml. It seems the curl rust package doesn't pin libcurl, and so it picks the latest. I can imagine that this libcurl is not compatible with my system libcurl. And making curl static solves that issue, as now it no longer depends on my system libcurl. But I am really guessing here, and stopped looking into this after my fixes unbroke my system :)
My backtrace also points to a libcurl/libssl issue.
It has a curious warning: Corrupted shared library list: 0x7ffff7313100 != 0x7fffe80031e0
(gdb) run build
Starting program: /home/ew/.cargo/bin/wasm-pack build
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff72ea640 (LWP 140377)]
[New Thread 0x7ffff70e9640 (LWP 140378)]
[Detaching after vfork from child process 140379]
warning: Corrupted shared library list: 0x7ffff7313100 != 0x7fffe80031e0
[Thread 0x7ffff70e9640 (LWP 140378) exited]
[Detaching after vfork from child process 140380]
Thread 2 "wasm-pack" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff72ea640 (LWP 140377)]
0x00007ffff7a8b2c3 in SSL_get_peer_certificate () from /usr/lib/libssl.so.1.1
(gdb) bt
#0 0x00007ffff7a8b2c3 in SSL_get_peer_certificate () from /usr/lib/libssl.so.1.1
#1 0x00007ffff7f4cd66 in ?? () from /usr/lib/libcurl.so.4
#2 0x00007ffff7f50f05 in ?? () from /usr/lib/libcurl.so.4
#3 0x00007ffff7f51fd7 in ?? () from /usr/lib/libcurl.so.4
#4 0x00007ffff7f09149 in ?? () from /usr/lib/libcurl.so.4
#5 0x00007ffff7f22508 in ?? () from /usr/lib/libcurl.so.4
#6 0x00007ffff7f23b06 in curl_multi_perform () from /usr/lib/libcurl.so.4
#7 0x00007ffff7efbd0c in curl_easy_perform () from /usr/lib/libcurl.so.4
#8 0x00005555557054c0 in wasm_pack::manifest::Crate::return_api_call_result ()
#9 0x0000555555704f98 in wasm_pack::manifest::Crate::return_wasm_pack_latest_version ()
#10 0x00005555556c5b14 in wasm_pack::build::check_wasm_pack_versions ()
#11 0x00005555556a9745 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#12 0x00005555556a6c53 in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#13 0x0000555555c72fd3 in alloc::boxed::{impl#44}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> ()
at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/alloc/src/boxed.rs:1636
#14 alloc::boxed::{impl#44}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> ()
at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/alloc/src/boxed.rs:1636
#15 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:106
#16 0x00007ffff7cdf259 in start_thread () from /usr/lib/libpthread.so.0
#17 0x00007ffff7e105e3 in clone () from /usr/lib/libc.so.6
I had a different problem with similar outcome: wasm-pack always segfaulted on wasm-pack build.
For me the solution was to downgrade from wasm-pack 0.10.x to 0.9.1 like this:
cargo install wasm-pack --version 0.9.1
Apparently 0.10.x introduced a bug
For me the solution was to downgrade from wasm-pack 0.10.x to 0.9.1
This worked for me here.
In my case I was missing crate-type metadata at Cargo.toml
[lib]
crate-type = ["cdylib", "rlib"]
Consider docs as reference
Edit: it seems not to be related to crate-type metadata. Installing version 0.9.1 solves the issue. Installing version 0.9.1 and installing version 0.10.1 also solves the issue.
You can recreate the issue with this docker image:
# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.205.2/containers/javascript-node/.devcontainer/base.Dockerfile
# [Choice] Node.js version (use -bullseye variants on local arm64/Apple Silicon): 16, 14, 12, 16-bullseye, 14-bullseye, 12-bullseye, 16-buster, 14-buster, 12-buster
ARG VARIANT="16"
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:0-${VARIANT}
# Install emscripten dependencies
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends cmake git python3 python3-pip
ENV EMSDK /emsdk
RUN git clone https://github.com/emscripten-core/emsdk.git ${EMSDK}
RUN cd ${EMSDK} \
&& ./emsdk install 1.40.1 \
&& ./emsdk activate 1.40.1 \
&& . ./emsdk_env.sh
USER node
# Install rust via rustup
ARG RUST_VERSION=1.56.1
RUN curl https://sh.rustup.rs -sSf | \
sh -s -- -y --default-toolchain $RUST_VERSION && \
. ~/.cargo/env && \
rustup target add asmjs-unknown-emscripten && \
rustup target add wasm32-unknown-emscripten && \
rustup target add wasm32-unknown-unknown
RUN echo "source ~/.cargo/env" >> ~/.bashrc
An vscode dev container is included if someone else is interested:
{
"name": "Node.js",
"build": {
"dockerfile": "Dockerfile",
"args": { "VARIANT": "16" }
},
"settings": {},
"extensions": [
"dbaeumer.vscode-eslint",
"ms-vscode.cpptools-extension-pack",
"rust-lang.rust",
"serayuzgur.crates"
],
"remoteUser": "node",
"features": {}
}
For me, it works fine if I install without default features (--no-defaults-features).
In my case I was missing
crate-typemetadata atCargo.toml
My Cargo.toml already has the crate-type metadata. But my wasm-pack project is set up as a sub-module. I wonder if cargo is ignoring it... gotta test it!
Edit: My wasm-pack project was inside a workspace. I added an empty
[workspace]in myCargo.tomlto exclude it from the main workspace.Now I'm back to
0.10.1without the segfault.
It outright failed with a custom SSL-certificate installed for localhost:
==19091== Invalid read of size 8
==19091== at 0x4D652C3: SSL_get_peer_certificate (in /usr/lib/libssl.so.1.1)
==19091== by 0x4904D65: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x4908F04: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x4909FD6: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48C1148: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48DA507: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48DBB05: curl_multi_perform (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48B3D0B: curl_easy_perform (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x2BFE8F: wasm_pack::manifest::Crate::return_api_call_result (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x2BF944: wasm_pack::manifest::Crate::return_wasm_pack_latest_version (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x272A33: wasm_pack::build::check_wasm_pack_versions (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x2533F4: _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h929fb148881a151bE.llvm.7723325994159813072 (in /home/user/.cargo/bin/wasm-pack)
==19091== Address 0x1000001b7 is not stack'd, malloc'd or (recently) free'd
==19091==
==19091==
==19091== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==19091== Access not within mapped region at address 0x1000001B7
==19091== at 0x4D652C3: SSL_get_peer_certificate (in /usr/lib/libssl.so.1.1)
==19091== by 0x4904D65: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x4908F04: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x4909FD6: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48C1148: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48DA507: ??? (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48DBB05: curl_multi_perform (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x48B3D0B: curl_easy_perform (in /usr/lib/libcurl.so.4.7.0)
==19091== by 0x2BFE8F: wasm_pack::manifest::Crate::return_api_call_result (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x2BF944: wasm_pack::manifest::Crate::return_wasm_pack_latest_version (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x272A33: wasm_pack::build::check_wasm_pack_versions (in /home/user/.cargo/bin/wasm-pack)
==19091== by 0x2533F4: _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h929fb148881a151bE.llvm.7723325994159813072 (in /home/user/.cargo/bin/wasm-pack)
After I removed the custom certificate, it still made a segmentation fault, but the build step was started.
It could also be that this behavior was just undefined behavior.
Same issue here on a clean install:
$ rustc -V
rustc 1.57.0 (Arch Linux rust 1:1.57.0-1)
$ wasm-pack -V
wasm-pack 0.10.1
$ wasm-pack new hello-wasm
[INFO]: Installing cargo-generate...
Segmentation fault (core dumped)
Works when downgrading to 0.9.1
This issue is fixed after https://github.com/rustwasm/wasm-pack/pull/1176 merges. In particular this binaryen upgrade fixed the sigsegv.
Until that PR merges, you an use this command to get the fix:
cargo install --git https://github.com/frewsxcv/wasm-pack.git --branch patch-2
Dunno if that helps(I don't even know if my seg fault was related), but I was able to solve the issue by installing wasm-pack from aur instead of cargo. So:
-
cargo uninstall wasm-pack -
yay wasm-pack - profit
I actually get this in dmesg:
[74401.892295] traps: wasm-pack[266603] general protection fault ip:7f2d195ff068 sp:7f2d1900cfe8 error:0
[74431.674723] traps: wasm-pack[266800] general protection fault ip:7f74b9fff068 sp:7f74b997afe8 error:0 in libcrypto.so.3.0.8[7f74b9ead000+257000]
This issue is fixed after #1176 merges. In particular this binaryen upgrade fixed the sigsegv.
Until that PR merges, you an use this command to get the fix:
cargo install --git https://github.com/frewsxcv/wasm-pack.git --branch patch-2
I still get a segfault with this.
This issue is fixed after #1176 merges. In particular this binaryen upgrade fixed the sigsegv. Until that PR merges, you an use this command to get the fix:
cargo install --git https://github.com/frewsxcv/wasm-pack.git --branch patch-2I still get a segfault with this.
Did you try latest master? After #1290 was merged I believe it should work.
I can't reproduce the segfault at all as of now. Not even with the command line from my previous comment. That's concerning.
Note, whichever version I use (via curl, via cargo package, via cargo install --force, I do get:
[WARN]: :-) There's a newer version of wasm-pack available, the new version is: 0.11.1, you are using: 0.10.3. To update, navigate to: https://rustwasm.github.io/wasm-pack/installer/
wasm-pack --version reports 0.10.3.
I just observed the issue again, with wasm-pack 0.10.3. I then installed from this repo main branch manually, and this time it worked, on version 0.11.1.