In the archive - coreutils.nodbg.zip - you will find two files, coreutils.nodbg.wasm and coreutils.nodbg.opt.wasm.
Unfortunately, they're fairly large, but that's as far as I could get for now. Maybe you'll be able to reduce them further and get to the bottom of the issue with wasm-reduce, but I couldn't spend more time on it.
Initially I've built the original source code in a release mode, which, combined with wasm-opt --asyncify -Os, introduced an infinite loop in the resulting WebAssembly, and I couldn't figure out what's going on.
After rebuilding in debug mode, I'm getting a [slightly more helpful] runtime assertion panic somewhere in initialisation of the app (when it tries to allocate data for a HashMap), and that panic is not reproducible by the original app, suggesting that some values were indeed misoptimized.
My initial assumption was that this is some bug specific to Asyncify, but, by slowly eliminating different options, got down to just -O1.
coreutils.nodbg.opt.wasm is produced with
$ wasm-opt.exe coreutils.nodbg.wasm -O1 -g -o coreutils.nodbg.opt.wasm
using wasm-opt from the latest commit on master (cd0cc95), however I could reproduce the issue with older versions as well - should be easy to do so using the command above.
To reproduce the issue, install a WASI-compatible runner, e.g. Wasmtime or Wasmer, and invoke it on both Wasm files.
This is what I'm seeing on the unoptimised file:
$ wasmtime -g coreutils.nodbg.wasm
coreutils.nodbg 0.0.1 (multi-call binary)
Usage: coreutils.nodbg [function [arguments...]]
Currently defined functions/utilities:
base32, base64, basename, cat, cksum, comm, cp, cut, date, df,
dircolors, dirname, echo, env, expand, expr, factor, false, fmt, fold,
hashsum, head, join, link, ln, ls, md5sum, mkdir, mktemp, more, mv, nl,
od, paste, printenv, printf, ptx, pwd, readlink, realpath, relpath, rm,
rmdir, seq, sha1sum, sha224sum, sha256sum, sha3-224sum, sha3-256sum,
sha3-384sum, sha3-512sum, sha384sum, sha3sum, sha512sum, shake128sum,
shake256sum, shred, shuf, sleep, sort, split, sum, tac, tail, tee, test,
tr, true, truncate, tsort, unexpand, uniq, wc, yes
and the optimised one:
$ wasmtime -g coreutils.nodbg.opt.wasm
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: LayoutErr { private: () }', C:\Users\rreverser\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\src/libcore/alloc/layout.rs:231:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `coreutils.nodbg.opt.wasm`
Caused by:
0: failed to invoke command default
1: wasm trap: unreachable
wasm backtrace:
0: 0x55cdd9 - <unknown>!__rust_start_panic
1: 0x55bf3e - <unknown>!rust_panic
2: 0x55bc75 - <unknown>!std::panicking::rust_panic_with_hook::hb8132b4308a71007
3: 0x55baca - <unknown>!rust_begin_unwind
4: 0x568654 - <unknown>!core::panicking::panic_fmt::hdd2ab611a748a491
5: 0x56d5ae - <unknown>!core::option::expect_none_failed::habae0dd01495a6a7
6: 0x339708 - <unknown>!core::result::Result<T,E>::unwrap::h0b29ccc7c9c10d07
7: 0x89b8 - <unknown>!core::alloc::layout::Layout::pad_to_align::hae1edfd09d682fcc
8: 0x5db74 - <unknown>!core::alloc::layout::Layout::array::h630440cfaca600e0
9: 0x57b73 - <unknown>!hashbrown::raw::calculate_layout::h32a6c9dc2acba081
10: 0x594fe - <unknown>!hashbrown::raw::RawTable<T>::new_uninitialized::h92067dc36e22c506
11: 0x59b10 - <unknown>!hashbrown::raw::RawTable<T>::try_with_capacity::h64ecb1c3ee6c48f1
12: 0x5864c - <unknown>!hashbrown::raw::RawTable<T>::resize::h1c5680148fe8f2d3
13: 0x58216 - <unknown>!hashbrown::raw::RawTable<T>::reserve_rehash::h36d80382ea8e9ffc
14: 0x5a96b - <unknown>!hashbrown::raw::RawTable<T>::reserve::h96e5457f885fde23
15: 0x5a872 - <unknown>!hashbrown::raw::RawTable<T>::insert::hd555411ed0fee9f1
16: 0x77f8e - <unknown>!hashbrown::map::HashMap<K,V,S>::insert::h263136bf7b5163b1
17: 0x44e23 - <unknown>!std::collections::hash::map::HashMap<K,V,S>::insert::h659bd993b5cd211f
18: 0xe449 - <unknown>!coreutils::util_map::h81ccd6dc74a16eac
19: 0x7d64 - <unknown>!coreutils::main::h791587a0c1680f0e
20: 0x4cd5c - <unknown>!std::rt::lang_start::{{closure}}::h14ee8eacd196f15d
21: 0x55aa3b - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::hd2bb8386068f691a
22: 0x55c02a - <unknown>!std::rt::lang_start_internal::h66de5b0ec01e6d33
23: 0x4cd33 - <unknown>!std::rt::lang_start::h01445dbe67544740
24: 0x849f - <unknown>!__original_main
25: 0x7cad - <unknown>!_start
In the archive - coreutils.nodbg.zip - you will find two files,
coreutils.nodbg.wasmandcoreutils.nodbg.opt.wasm.Unfortunately, they're fairly large, but that's as far as I could get for now. Maybe you'll be able to reduce them further and get to the bottom of the issue with
wasm-reduce, but I couldn't spend more time on it.Initially I've built the original source code in a release mode, which, combined with
wasm-opt --asyncify -Os, introduced an infinite loop in the resulting WebAssembly, and I couldn't figure out what's going on.After rebuilding in debug mode, I'm getting a [slightly more helpful] runtime assertion panic somewhere in initialisation of the app (when it tries to allocate data for a
HashMap), and that panic is not reproducible by the original app, suggesting that some values were indeed misoptimized.My initial assumption was that this is some bug specific to Asyncify, but, by slowly eliminating different options, got down to just
-O1.coreutils.nodbg.opt.wasmis produced withusing
wasm-optfrom the latest commit onmaster(cd0cc95), however I could reproduce the issue with older versions as well - should be easy to do so using the command above.To reproduce the issue, install a WASI-compatible runner, e.g. Wasmtime or Wasmer, and invoke it on both Wasm files.
This is what I'm seeing on the unoptimised file:
and the optimised one: