wasm-opt fails due to duplicated symbol

[dpc]

Describe the Bug

wasm-opt fails with:

<==
getInt8: 146 (at 72306)
getInt8: 1 (at 72307)
getU32LEB: 146 ==>
getInlineString: _dyn_core_13c557ea88c6c04a___ops__function__FnMut_____Output______as_wasm_bindgen_10a7af47601b6690___closure__WasmClosure___describe__invoke______ ==>
<==
getInt8: 0 (at 72454)
getU32LEB: 0 ==>
<==
getInt8: 189 (at 72455)
getInt8: 247 (at 72456)
getInt8: 2 (at 72457)
getU32LEB: 48061 ==>
read one
<==
<==
getInt8: 146 (at 72458)
getInt8: 1 (at 72459)
getU32LEB: 146 ==>
getInlineString: _dyn_core_13c557ea88c6c04a___ops__function__FnMut_____Output______as_wasm_bindgen_10a7af47601b6690___closure__WasmClosure___describe__invoke______ ==>
[parse exception: duplicate export name (at 0:72606)]
Fatal: error parsing wasm. here is what we read up to the error:
(module
 (type $0 (func (param externref) (result externref)))
 (type $1 (func (param externref) (result i32)))
 (type $2 (func (param externref externref)))
 (type $3 (func (result externref)))

I can't tell why. I tried a lot of things: mostly changing version of everything I could: relevant dependencies, involved tools, rust toolchain; tweaking build options.

I have no idea why this is happening.

Steps to Reproduce

It's in our internal project and I can't share it RN.

[daxpedda]

Do you by any chance run wasm-opt before running wasm-bindgen-cli post-processing? If so, you have to run the post-processing by wasm-bindgen first!

[dpc]

I think cargo build takes care of #[wasm_bindgen] things, then the script run wasm-pack that triggers wasm-opt.

@daxpedda If you can point me to resources explaining it, I can probably verify and figure out stuff. Thank you for help!

[daxpedda]

I'm not aware where a detail like that is documented. But AFAIK wasm-pack does the right thing. Compiles with Rust -> post-processes with wasm-bindgen-cli -> optionally calls wasm-opt. So it is probably unrelated.

Let me know when you have something reproducible to share I can look at!

[dpc]

@daxpedda Welll... I do have something reproducible, but it is far from anything "minimized". Our app is source-available, and last public release is also affected. We use Nix flakes to make dev process smooth, so if you have / don't mind setting up Nix you could repro it with just:

> g clone git@github.com:fedixyz/fedi.git
> cd fedi
> nix develop
> env CARGO_PROFILE=release ./scripts/build-wasm.sh

...
    Finished `release` profile [optimized + debuginfo] target(s) in 5m 04s
[INFO]: found wasm-opt at "/nix/store/9g4bdnnr95j7a01dq9in670zxi8qd8al-binaryen-116/bin/wasm-opt"
[INFO]: Optimizing wasm binaries with `wasm-opt`...
[parse exception: duplicate export name (at 0:53002)]
Fatal: error parsing wasm (try --debug for more info)
Error: failed to execute `wasm-opt`: exited with exit status: 1
  full command: "/nix/store/9g4bdnnr95j7a01dq9in670zxi8qd8al-binaryen-116/bin/wasm-opt" "/home/dpc/tmp/fedi/target-nix/pkgs/wasm-pack/wasm-pack-out/fedi_wasm_bg.wasm" "-o" "/home/dpc/tmp/fedi/target-nix/pkgs/wasm-pack/wasm-pack-out/fedi_wasm_bg.wasm-opt.wasm" "-O"
To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
Caused by: failed to execute `wasm-opt`: exited with exit status: 1
  full command: "/nix/store/9g4bdnnr95j7a01dq9in670zxi8qd8al-binaryen-116/bin/wasm-opt" "/home/dpc/tmp/fedi/target-nix/pkgs/wasm-pack/wasm-pack-out/fedi_wasm_bg.wasm" "-o" "/home/dpc/tmp/fedi/target-nix/pkgs/wasm-pack/wasm-pack-out/fedi_wasm_bg.wasm-opt.wasm" "-O"
To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.

but get ready for a lot of building. Alternatively, just looking at it, might reveal something, though AFAICT it is rather standard Rust project that does wasm-pack:

https://github.com/fedixyz/fedi/blob/3f54e425b64d910b282d3cc7edc465141e9bc993/scripts/build-wasm.sh#L36

[daxpedda]

How about you compile this app with cargo build --target wasm32-unknown-unknown on your side and send me the .wasm file instead. Make sure that you are compiling with wasm-bindgen v0.2.99.

[dpc]

Do you care if it's debug or release build?

The newest bindgen I have easy access to is 0.2.95. I'll have to hack it a bit to get 0.2.99, but will get back to you with it.

[daxpedda]

Do you care if it's debug or release build?

Yes, sorry, should be a release build. I'm assuming your bug happens with a release build? AFAIK wasm-pack only triggers wasm-opt by default when its a release build.

In any case, if the bug is triggered in a dev build, we should still look into it. While we don't intend to be compatible with wasm-opt in dev builds, I'm assuming that wasm-opt found a bug in the resulting Wasm module we should fix.

[dpc]

@daxpedda https://dpc.pw/fedi_wasm_bg.wasm

[daxpedda]

I specifically meant only running cargo build --target wasm32-unknown-unknown, not post-processing it with wasm-bindgen. Rustc compiles a *.wasm file which is then post-processed by wasm-bindgen-cli. To debug this I only need the first step. The file you uploaded is already post-processed by wasm-bindgen-cli. Let me know if anything is unclear!

But there clearly a bug in rustc or wasm-bindgen, because this is an invalid Wasm module. So this isn't an issue with wasm-opt.

[dpc]

Oh, sorry, I forgot about it over the weekend. 🤦

So this is what I'm doing now:

> cargo build --release --target wasm32-unknown-unknown -p fedi-wasm
...
    Finished `release` profile [optimized + debuginfo] target(s) in 8m 15s
> ls -alh target-nix/pkg/fedi-wasm/wasm32-unknown-unknown/release/fedi_wasm.wasm
-rwxr-xr-x 2 dpc dpc 194M Dec 24 15:00 target-nix/pkg/fedi-wasm/wasm32-unknown-unknown/release/fedi_wasm.wasm
> cp target-nix/pkg/fedi-wasm/wasm32-unknown-unknown/release/fedi_wasm.wasm ~/pub/blog/static/fedi_wasm-raw.wasm

fedi-wasm is the package, target dir is a bit weird because we're doing some CARGO_BUILD_TARGET_DIR trickery.

Should be here now: https://dpc.pw/fedi_wasm-raw.wasm