Closed BarbossHack closed 1 year ago
If I install wasm-pack with this command, it works, but it should also work with cargo install wasm-pack
isn't it ?
curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh
same for me, I thought something with openssl but then I'm not the only one, as I installed this programm today the first time Running on debian testing x86. wasm-pack 0.10.3, from cargo install / gitt checkout
stacktrace:
(gdb) bt
#0 0x000055555587c5c4 in OPENSSL_sk_value ()
#1 0x00005555558839fa in X509_STORE_add_lookup ()
#2 0x00007ffff78c768b in X509_STORE_load_file_ex (ctx=0x7ffff0010d40, file=file@entry=0x7ffff0009ad0 "/etc/ssl/certs/ca-certificates.crt", libctx=0x555555e63740 <TLS_client_method_data.14>, propq=0x0)
at ../crypto/x509/x509_d2.c:51
#3 0x00007ffff7aa6e23 in SSL_CTX_load_verify_file (ctx=<optimized out>, CAfile=CAfile@entry=0x7ffff0009ad0 "/etc/ssl/certs/ca-certificates.crt") at ../ssl/ssl_lib.c:4411
#4 0x00007ffff7f64bee in ossl_connect_step1 (data=data@entry=0x7ffff0001ef0, conn=conn@entry=0x7ffff0008de0, sockindex=sockindex@entry=0) at vtls/openssl.c:3094
#5 0x00007ffff7f677b7 in ossl_connect_common (data=0x7ffff0001ef0, conn=0x7ffff0008de0, sockindex=0, nonblocking=true, done=0x7ffff6c80333) at vtls/openssl.c:4127
#6 0x00007ffff7f68808 in Curl_ssl_connect_nonblocking (data=data@entry=0x7ffff0001ef0, conn=conn@entry=0x7ffff0008de0, isproxy=isproxy@entry=false, sockindex=sockindex@entry=0, done=done@entry=0x7ffff6c80333)
at vtls/vtls.c:371
#7 0x00007ffff7f1f456 in https_connecting (done=0x7ffff6c80333, data=0x7ffff0001ef0) at ./debian/build/lib/http.c:1597
#8 Curl_http_connect (data=0x7ffff0001ef0, done=0x7ffff6c80333) at ./debian/build/lib/http.c:1523
#9 0x00007ffff7f3855c in protocol_connect (protocol_done=0x7ffff6c80333, data=0x7ffff0001ef0) at ./debian/build/lib/multi.c:1775
#10 multi_runsingle (multi=multi@entry=0x7ffff00011e0, nowp=nowp@entry=0x7ffff6c803b0, data=data@entry=0x7ffff0001ef0) at ./debian/build/lib/multi.c:2091
#11 0x00007ffff7f394d6 in curl_multi_perform (multi=multi@entry=0x7ffff00011e0, running_handles=running_handles@entry=0x7ffff6c804b8) at ./debian/build/lib/multi.c:2684
#12 0x00007ffff7f0fc4b in easy_transfer (multi=<optimized out>) at ./debian/build/lib/easy.c:662
#13 easy_perform (events=false, data=0x7ffff0001ef0) at ./debian/build/lib/easy.c:752
#14 curl_easy_perform (data=0x7ffff0001ef0) at ./debian/build/lib/easy.c:771
#15 0x00005555556bd26a in wasm_pack::manifest::Crate::return_api_call_result ()
#16 0x00005555556bcd41 in wasm_pack::manifest::Crate::return_wasm_pack_latest_version ()
#17 0x0000555555674524 in wasm_pack::build::check_wasm_pack_versions ()
#18 0x00005555556658e5 in _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h92c30cc87178789cE.llvm.6905629553221003568 ()
#19 0x000055555566361a in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
#20 0x0000555555b90be3 in alloc::boxed::{impl#44}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1951
#21 alloc::boxed::{impl#44}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1951
#22 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#23 0x00007ffff7d7484a in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#24 0x00007ffff7df82cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
ctx looks corrupted: X509_STORE_load_file_ex (ctx=0x7ffff0010d40,) but it's probably triggerd outside of openssl
with address sanitizer:
> /tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack build
AddressSanitizer:DEADLYSIGNAL
=================================================================
==819046==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x555c878a7aa4 bp 0x7f6913cfa0e0 sp 0x7f6913cfa0a8 T1)
==819046==The signal is caused by a READ memory access.
==819046==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used.
#0 0x555c878a7aa4 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x135baa4)
#1 0x555c878aeb5a (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x1362b5a)
#2 0x7f6917f7468a (/lib/x86_64-linux-gnu/libcrypto.so.3+0x2d568a)
#3 0x7f6918611bed (/lib/x86_64-linux-gnu/libcurl.so.4+0x74bed)
#4 0x7f69186147b6 (/lib/x86_64-linux-gnu/libcurl.so.4+0x777b6)
#5 0x7f6918615807 (/lib/x86_64-linux-gnu/libcurl.so.4+0x78807)
#6 0x7f69185cc455 (/lib/x86_64-linux-gnu/libcurl.so.4+0x2f455)
#7 0x7f69185e555b (/lib/x86_64-linux-gnu/libcurl.so.4+0x4855b)
#8 0x7f69185e64d5 (/lib/x86_64-linux-gnu/libcurl.so.4+0x494d5)
#9 0x7f69185bcc4a (/lib/x86_64-linux-gnu/libcurl.so.4+0x1fc4a)
#10 0x555c86f5b928 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0xa0f928)
#11 0x555c86fdd0cc (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0xa910cc)
#12 0x555c86fdb9fa (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0xa8f9fa)
#13 0x555c86fd8a17 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0xa8ca17)
#14 0x555c86fd838e (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0xa8c38e)
#15 0x555c86d5dcb2 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x811cb2)
#16 0x555c86d39a0f (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7eda0f)
#17 0x555c86d29894 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7dd894)
#18 0x555c86d1371c (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7c771c)
#19 0x555c86d49fac (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7fdfac)
#20 0x555c86d3dc10 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7f1c10)
#21 0x555c86d3e01c (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7f201c)
#22 0x555c86d3d834 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7f1834)
#23 0x555c86d4a10f (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7fe10f)
#24 0x555c86d13112 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7c7112)
#25 0x555c86d4a52d (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7fe52d)
#26 0x555c89f6f6a8 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3a236a8)
#27 0x555c89f6f9a6 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3a239a6)
#28 0x555c8a0491e8 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3afd1e8)
#29 0x7f6918421849 (/lib/x86_64-linux-gnu/libc.so.6+0x87849)
#30 0x7f69184a52cb (/lib/x86_64-linux-gnu/libc.so.6+0x10b2cb)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x135baa4)
Thread T1 created by T0 here:
#0 0x555c86cdb1dc (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x78f1dc)
#1 0x555c8a048c1e (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3afcc1e)
#2 0x555c86d12082 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7c6082)
#3 0x555c86d138e0 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7c78e0)
#4 0x555c86d10bf2 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7c4bf2)
#5 0x555c86d57e32 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x80be32)
#6 0x555c86d5924a (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x80d24a)
#7 0x555c86d58385 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x80c385)
#8 0x555c86d4a68a (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7fe68a)
#9 0x555c86d29733 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7dd733)
#10 0x555c8a03b49e (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3aef49e)
#11 0x555c8a04f3dc (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3b033dc)
#12 0x555c89f7e099 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x3a32099)
#13 0x555c89f31171 (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x39e5171)
#14 0x555c86d2969f (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x7dd69f)
#15 0x555c86d5bccb (/tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack+0x80fccb)
==819046==ABORTING
currently searching were the memory gets corrupted
Just for you to know: it works when installing wasm-pack with x86_64-unknown-linux-musl
target
cargo install wasm-pack --force --target x86_64-unknown-linux-musl
can confirm musl-libc works, strange
It seems to come from here : https://github.com/rustwasm/wasm-pack/blob/10f30be713f03eae68df21b34a220c03b45d871f/src/manifest/mod.rs#L416-L418
...and in this exec()
call, if I set a breakpoint here...
...it runs well to this breakpoint, and then it crash with :
But it's weird, I don't understand why it's crashing in openssl here, as std::process::Command::output()
comes from the std which does not rely on openssl, and wasm-pack just try to run cargo metadata
command here...
Be carefull, there are two threads, one crashes in openssl, one waits for the result from a command.
but really strange bug, will debug a bit longer tonight :)
Indeed !
It seems related to https://github.com/rustwasm/wasm-pack/issues/823
It works with @TrueBrain fix here https://github.com/rustwasm/wasm-pack/issues/823#issuecomment-968285258 But not with @frewsxcv one (https://github.com/rustwasm/wasm-pack/issues/823#issuecomment-1242611318)
But @TrueBrain fix (adding "static-curl" feature) may not be the most elegant way... it would be like using musl, the real issue is somewhere else
hmm, could be,
I run it with MemorySanitizer and found this error: Uninitialized bytes in __interceptor_fopen64 at offset 0 inside [0x702000016c60, 27)
What looks like a wrong init in the curl static code, very strange.
(gdb) b __msan::ReportUMR
Breakpoint 4 at 0x55555573e8a2: file /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan_report.cpp, line 99.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/wasm-pack/target/x86_64-unknown-linux-gnu/debug/wasm-pack
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Uninitialized bytes in __interceptor_fopen64 at offset 0 inside [0x702000016c60, 27)
Breakpoint 4, ReportUMR () at /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan_report.cpp:99
99 /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan_report.cpp: No such file or directory.
(gdb) bt
#0 ReportUMR () at /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan_report.cpp:99
#1 0x00005555556f227e in PrintWarningWithOrigin () at /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan.cpp:242
#2 0x0000555555720c7e in __interceptor_fopen64 () at /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/../sanitizer_common/sanitizer_common_interceptors.inc:6087
#3 0x0000555556905765 in openssl_fopen (filename=<optimized out>, mode=<optimized out>) at crypto/o_fopen.c:114
#4 0x00005555568a5636 in BIO_new_file (filename=0x702000016c60 "/usr/local/ssl/openssl.cnf", mode=mode@entry=0x55555b8bf792 "rb") at crypto/bio/bss_file.c:62
#5 0x00005555568bec72 in def_load (conf=0x702000016c40, name=<optimized out>, line=0x0) at crypto/conf/conf_def.c:164
#6 0x00005555568bfff2 in CONF_modules_load_file (filename=filename@entry=0x0, appname=appname@entry=0x0, flags=flags@entry=50) at crypto/conf/conf_mod.c:129
#7 0x000055555699edb4 in openssl_config_int (settings=<optimized out>) at crypto/conf/conf_sap.c:69
#8 0x00005555568f9e90 in ossl_init_config () at crypto/init.c:292
#9 ossl_init_config_ossl_ () at crypto/init.c:290
#10 0x00007ffff7c8c928 in __pthread_once_slow (once_control=0x555560091160 <config>, init_routine=0x5555568f9e80 <ossl_init_config_ossl_>) at ./nptl/pthread_once.c:116
#11 0x000055555694b2c9 in CRYPTO_THREAD_run_once (once=once@entry=0x555560091160 <config>, init=init@entry=0x5555568f9e80 <ossl_init_config_ossl_>) at crypto/threads_pthread.c:118
#12 0x00005555568fa4d2 in OPENSSL_init_crypto (opts=opts@entry=30284, settings=settings@entry=0x0) at crypto/init.c:692
#13 0x0000555556862669 in OPENSSL_init_ssl (opts=30284, opts@entry=30272, settings=settings@entry=0x0) at ssl/ssl_init.c:190
#14 0x00007ffff7f62300 in ossl_init () at vtls/openssl.c:1212
#15 0x00007ffff7f0f69a in global_init (flags=<optimized out>, memoryfuncs=memoryfuncs@entry=true) at ./debian/build/lib/easy.c:167
#16 0x00007ffff7f0f84a in curl_global_init (flags=<optimized out>) at ./debian/build/lib/easy.c:229
#17 0x000055555866753d in curl::init::{{closure}} () at /home/tuxcoder/.cargo/registry/src/github.com-1ecc6299db9ec823/curl-0.4.43/src/lib.rs:103
#18 0x0000555558647e97 in std::sync::once::{{impl}}::call_once::{{closure}}<closure-0> ()
at /home/tuxcoder/.rustup/toolchains/nightly-2021-06-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:261
#19 0x000055555b2c38f6 in std::sync::once::Once::call_inner (self=0x555560092a10 <curl::init::INIT>, ignore_poisoning=false, init=...)
at /home/tuxcoder/.rustup/toolchains/nightly-2021-06-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:418
#20 0x0000555558647b3c in std::sync::once::Once::call_once<closure-0> (self=0x555560092a10 <curl::init::INIT>, f=...)
at /home/tuxcoder/.rustup/toolchains/nightly-2021-06-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:261
#21 0x00005555586673ed in curl::init () at /home/tuxcoder/.cargo/registry/src/github.com-1ecc6299db9ec823/curl-0.4.43/src/lib.rs:96
#22 0x00005555556f2026 in curl::INIT_CTOR::init_ctor () at /home/tuxcoder/.cargo/registry/src/github.com-1ecc6299db9ec823/curl-0.4.43/src/lib.rs:147
#23 0x00007ffff7c29333 in call_init (env=<optimized out>, argv=0x7fffffffe5a8, argc=1) at ../csu/libc-start.c:145
#24 __libc_start_main_impl (main=0x5555557e7c50 <main>, argc=1, argv=0x7fffffffe5a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe598) at ../csu/libc-start.c:376
#25 0x00005555556f2051 in _start ()
OK to strange bug, looks like very deep, will continue another time, or accept the workaround
MemorySanitizer could also be another issue/false positive, not sure
I ended up using this command to install wasm-pack (without having to install musl target)
cargo install wasm-pack --features curl/static-curl
replicated bug and fix (both curling the installer and curl/static-curl
feature flag) on arch (6.0.5-arch1-g14-1)
Also #1203
tldr: install wasm-pack with --no-default-features
to use the system OpenSSL instead of the vendored OpenSSL:
cargo install wasm-pack --no-default-features
Why does this work?
wasm-pack Cargo.toml has this flag:
[features]
# OpenSSL is vendored by default, can use system OpenSSL through feature flag.
default = ['openssl/vendored']
Here is a strace if that helps?
I also tried upgrading OpenSSL in the project to see if that helped (if a backwards incompatible happened recently?), it did not.
I know it uses a vendored OpenSSL, but here's my versions:
$ openssl version
OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022)
$ uname -a
Linux kit 6.1.3-1-cachyos-cfs #1 SMP PREEMPT_DYNAMIC Thu, 05 Jan 2023 06:34:32 +0000 x86_64 GNU/Linux
$ rustc --version
rustc 1.68.0-nightly (0fb8b72ce 2023-01-06)
$ cargo 1.68.0-nightly (8c460b223 2023-01-04)
Why is openssl needed as a default feature? Is there an issue on some platforms?
Please try out v0.12.0 from one of the following ways:
🐛 Bug description
When I run wasm-pack (either build, or new, ...), I get a "Segmentation fault (core dumped)"
🤔 Expected Behavior
It should not panic with a segmentation fault
👟 Steps to reproduce
🌍 Your environment
os: fedora 36 wasm-pack version: 0.10.3 rustc version: 1.64.0 (a55dd71d5 2022-09-19)