core dumped

[jpentland]

🐛 Bug description

312115 Segmentation fault (core dumped)

When running:
wasm-pack build --no-typescript --target bundler --out-dir build --out-name index --release

🤔 Expected Behavior

No segfault.

👟 Steps to reproduce

I was trying to build the cloudflare rustwasm template. I placed the current state of my repo in a fork.

In ths case, wasm-pack was being started by cloudflarezs "worker-build" tool, which in turn was started by "wrangler dev".

The wasm-pack command was found via strace.

However, cloning the repo and immediately running wasm-pack still seems to cause the segfault.

git clone git@github.com:jpentland/dadgum.git -b coredump
cd dadgum
wasm-pack build --no-typescript --target bundler --out-dir build --out-name index --release

🌍 Your environment

Include the relevant details of your environment.

wasm-pack version: wasm-pack 0.10.3
rustc version: rustc 1.67.1 (d5a82bbd2 2023-02-07)

[jpentland]

I compiled the debug version of wasm-pack and ran with gdb. Results below. It might be an issue with the libs on my local machine. Will look into it more later if I have time.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7ffff72156c0 (LWP 345231)]
[New Thread 0x7ffff70146c0 (LWP 345232)]
[Detaching after vfork from child process 345233]
[Thread 0x7ffff70146c0 (LWP 345232) exited]

Thread 2 "wasm-pack" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff72156c0 (LWP 345231)]
___pthread_rwlock_wrlock (rwlock=0x35) at pthread_rwlock_wrlock.c:26
26
int result = __pthread_rwlock_wrlock_full64 (rwlock, CLOCK_REALTIME, NULL);
(gdb) trace
Tracepoint 1 at 0x7ffff7c71d66: file /usr/src/debug/glibc/glibc/nptl/pthread_rwlock_common.c, line 603.

[jpentland]

Here's the full backtrace. Looks like it might not be related to wasm-pack at all.

0x00007ffff7c71d66 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6                                                                                                                                                                        
(gdb) bt                                                                                                                                                                                                                                      
#0  0x00007ffff7c71d66 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6                                                                                                                                                                    
#1  0x00007ffff77ca0ee in CRYPTO_THREAD_write_lock () from /usr/lib/libcrypto.so.3
#2  0x00007ffff7837ee5 in ?? () from /usr/lib/libcrypto.so.3
#3  0x00007ffff7837f81 in X509_STORE_add_cert () from /usr/lib/libcrypto.so.3
#4  0x00007ffff781c540 in X509_load_cert_crl_file_ex () from /usr/lib/libcrypto.so.3
#5  0x00007ffff781c696 in ?? () from /usr/lib/libcrypto.so.3
#6  0x00007ffff7837a4a in X509_STORE_load_file_ex () from /usr/lib/libcrypto.so.3
#7  0x00007ffff7f581ab in ?? () from /usr/lib/libcurl.so.4
#8  0x00007ffff7f5858d in ?? () from /usr/lib/libcurl.so.4
#9  0x0000555555b38a5e in bread_conv (bio=<optimized out>, data=<optimized out>, datal=<optimized out>, readbytes=0x7ffff7213380) at crypto/bio/bio_meth.c:123
#10 0x0000555555b378d5 in bio_read_intern (b=0x7ffff00149c0, data=data@entry=0x7ffff001a263, dlen=dlen@entry=5, readbytes=readbytes@entry=0x7ffff7213380) at crypto/bio/bio_lib.c:270
#11 0x0000555555b37ec7 in BIO_read (b=<optimized out>, data=data@entry=0x7ffff001a263, dlen=dlen@entry=5) at crypto/bio/bio_lib.c:296
#12 0x0000555555ae4f6d in ssl3_read_n (s=s@entry=0x7ffff0012860, n=n@entry=5, max=5, extend=extend@entry=0, clearold=clearold@entry=1, readbytes=readbytes@entry=0x7ffff7213448) at ssl/record/rec_layer_s3.c:309
#13 0x0000555555ae8f41 in ssl3_get_record (s=s@entry=0x7ffff0012860) at ssl/record/ssl3_record.c:207
#14 0x0000555555ae6e20 in ssl3_read_bytes (s=<optimized out>, type=22, recvd_type=0x7ffff72135ec, buf=0x7ffff0014d00 "\001", len=4, peek=0, readbytes=0x7ffff72135f0) at ssl/record/rec_layer_s3.c:1320
#15 0x0000555555b16db8 in tls_get_message_header (s=s@entry=0x7ffff0012860, mt=mt@entry=0x7ffff7213664) at ssl/statem/statem_lib.c:1160
#16 0x0000555555b0c398 in read_state_machine (s=0x7ffff0012860) at ssl/statem/statem.c:579
#17 state_machine (s=0x7ffff0012860, server=0) at ssl/statem/statem.c:434
#18 0x00007ffff7f5b03d in ?? () from /usr/lib/libcurl.so.4
#19 0x00007ffff7f60d6c in ?? () from /usr/lib/libcurl.so.4
#20 0x00007ffff7f58803 in ?? () from /usr/lib/libcurl.so.4
#21 0x00007ffff7efe069 in ?? () from /usr/lib/libcurl.so.4
#22 0x00007ffff7f0045a in ?? () from /usr/lib/libcurl.so.4
#23 0x00007ffff7efa69f in ?? () from /usr/lib/libcurl.so.4
#24 0x00007ffff7f35589 in ?? () from /usr/lib/libcurl.so.4
#25 0x00007ffff7f385ce in curl_multi_perform () from /usr/lib/libcurl.so.4
#26 0x00007ffff7f0d2a4 in curl_easy_perform () from /usr/lib/libcurl.so.4
#27 0x0000555555880758 in curl::easy::handler::Easy2<wasm_pack::manifest::Collector>::perform<wasm_pack::manifest::Collector> (self=0x7ffff7213ef8)
    at /home/jp/.cargo/registry/src/github.com-1ecc6299db9ec823/curl-0.4.44/src/easy/handler.rs:3163
#28 0x000055555575a759 in wasm_pack::manifest::Crate::check_wasm_pack_latest_version () at src/manifest/mod.rs:247
#29 0x000055555575a237 in wasm_pack::manifest::Crate::return_latest_wasm_pack_version () at src/manifest/mod.rs:220
#30 0x000055555575979e in wasm_pack::manifest::Crate::return_api_call_result (current_time=<error reading variable: Cannot access memory at address 0x0>) at src/manifest/mod.rs:170
#31 0x0000555555759632 in wasm_pack::manifest::Crate::return_wasm_pack_latest_version () at src/manifest/mod.rs:165
#32 0x0000555555747826 in wasm_pack::build::check_wasm_pack_versions () at src/build/mod.rs:65
#33 0x00005555557354df in wasm_pack::background_check_for_updates::{closure#0} () at src/main.rs:30

[yogo1212]

I think I'm having the same issue while following the steps from https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm.

$ wasm-pack build --target web
Segmentation fault (core dumped)

EDIT:
Also stuck in pthread_rwlock_wrlock
Arch Linux, curl 7.87.0-1, openssl 3.0.7-4, glibc 2.36-6 (pthread)

[jpentland]

I was able to work around the issue by removing the cargo version of the tool and installing it from my distro's package manager (in my case pacman, archlinux)

[kulak]

I have the same issue. Here is journalctl trace:

wasm-pack build --target=web --dev --no-default-features --features=hydrate 

Stack trace of thread 289095:
#0  0x00007f45a76a1d66 __pthread_rwlock_wrlock (libc.so.6 + 0x8bd66)
#1  0x00007f45a6fca0ee CRYPTO_THREAD_write_lock (libcrypto.so.3 + 0x1ca0ee)
#2  0x00007f45a7037ee5 n/a (libcrypto.so.3 + 0x237ee5)
#3  0x00007f45a7037f81 X509_STORE_add_cert (libcrypto.so.3 + 0x237f81)
#4  0x00007f45a701c540 X509_load_cert_crl_file_ex (libcrypto.so.3 + 0x21c540)
#5  0x00007f45a701c696 n/a (libcrypto.so.3 + 0x21c696)
#6  0x00007f45a7037a4a X509_STORE_load_file_ex (libcrypto.so.3 + 0x237a4a)
#7  0x00007f45a786d1ab n/a (libcurl.so.4 + 0x701ab)
#8  0x00007f45a786d58d n/a (libcurl.so.4 + 0x7058d)
#9  0x0000561f7b434376 n/a (/home/dev/.cargo/bin/wasm-pack + 0x267376)
ELF object binary architecture: AMD x86-64

My environment is also Arch Linux.

It might be related to issue #650.

I was able to resolve the issue by following one of the comments:

cargo install wasm-pack --no-default-features 

[cryptoquick]

I was able to fix this by installing the musl toolchain.

rustup target add x86_64-unknown-linux-musl

On Arch, you must then sudo pacman -S musl

Then in wasm-pack: cargo install --path . --target=x86_64-unknown-linux-musl

Then you should be good to go.

[mb720]

Also on Arch Linux, I worked around the issue by rolling back the version:

cargo install wasm-pack@0.10.3