v1/decoders started throwing RuntimeError

[ffdead]

Hello, an existing project started breaking since yesterday with the following error:

failed to asynchronously prepare wasm: TypeError: WebAssembly.instantiate(): Import #0 module="env" error: module is not 
an object or function

RuntimeError: abort(TypeError: import object field 'env' is not an Object). Build with -s ASSERTIONS=1 for more info.

Website: https://www.pluto.app/
No code changes have been made in the last 3 months.

Experienced in:

• Chrome version 94.0.4606.81 (Official Build) (x86_64)
• Firefox version 92.0 (64-bit)
• macOS Catalina version 10.15.7

Files affected:
https://www.gstatic.com/draco/v1/decoders/draco_wasm_wrapper.js
https://www.gstatic.com/draco/v1/decoders/draco_decoder.wasm

[developer-umantech]

Same problem here., since yesterday.

• Chrome Version 94.0.4606.81

[tomfinegan]

@ffdead Should this repro by simply launching the site? It seems to be working at present. I have the same version of Chrome that you've reported.

Issues like this are why for the last few releases we've recommended using the versioned URLs. There was a release on Tuesday and the situation you're seeing could be caused by delayed gstatic propagation and/or edge caching, which only effects the unversioned (aka v1/decoders) URLs.

To go back to the last release update your site to pull the files from 1.4.2. The filenames are the same, but they live here:
https://www.gstatic.com/draco/versioned/decoders/1.4.2/

To use the latest release:
https://www.gstatic.com/draco/versioned/decoders/1.4.3/

edit: is -> are, typing is hard before coffee.

[ffdead]

Thanks @tomfinegan, yes the issue was there just by loading the website on desktop chrome/FF.

During QA of this project we had to disable draco for safari/iOS because the threejs loader would get stuck for some reason. Not sure if you ever heard that happening before?

Will try again tomorrow and potentially specify the old version.

Is there a likely reason why "old" models should break with the new version. Mostly wondering how to sync up blender export versions with the correct draco wasm.

Thanks!

[tomfinegan]

During QA of this project we had to disable draco for safari/iOS because the threejs loader would get stuck for some reason. Not sure if you ever heard that happening before?

This is new to me, and I don't see a similar problem in the tracker. If you have a repro case, or can outline the steps that end up causing a hang, please file an issue and we can take a look at it. FWIW I tried loading your site in Chrome and Safari on my iOS, and it seems to work fine there as well.

Is there a likely reason why "old" models should break with the new version. Mostly wondering how to sync up blender export versions with the correct draco wasm.

No, older models should decode properly with the latest release. If you have a model compressed with a previous Draco release that does not decode with the latest release, please file an issue about the model (and share the model with us, if that's possible).

[tomfinegan]

Is there a likely reason why "old" models should break with the new version. Mostly wondering how to sync up blender export versions with the correct draco wasm.

No, older models should decode properly with the latest release. If you have a model compressed with a previous Draco release that does not decode with the latest release, please file an issue about the model (and share the model with us, if that's possible).

Actually, I forgot about this one:
#704

There is a report of high quantization values with 1.3.6 causing issues at decode time in 1.4.1. Is it possible that your input used similar settings?

[donmccurdy]

During QA of this project we had to disable draco for safari/iOS because the threejs loader would get stuck for some reason. Not sure if you ever heard that happening before?

I've heard a few reports similar to this from three.js users, but most of those reports have not been reproducible on my iOS devices. If you have examples to share please feel free to file an issue on three.js as well. One exception would be mrdoob/three.js#22445 – using multiple DRACOLoader instances at the same time may cause issues (in addition to allocating more Web Workers than is good for performance and memory) so it's better to reuse the same DRACOLoader instance or dispose of old ones.

Is there a likely reason why "old" models should break with the new version. Mostly wondering how to sync up blender export versions with the correct draco wasm.

Also see #717 – I'm not quite sure what the relationship between normal Draco builds and "gltf" Draco builds is, or whether it matters for most users.

[driescroons]

Same issue here, but on windows. I was thinking about setting up a repo, but figured that the pmndrs market was probably having the same issue:
https://market.pmnd.rs/model/zombie-car

@donmccurdy does the model load on your device?

[donmccurdy]

The model itself loads on my iPhone when opened in my viewer (screenshot below, not using Google CDN) but not in the market.pmnd.rs page (either on mobile or on desktop). I think the specific application code, three.js versions, and decoder versions used there could all be important.

[ffdead]

I'm happy to report that this error has magically fixed itself, we haven't changed the website code and now the models load again 🤷

During QA of this project we had to disable draco for safari/iOS because the threejs loader would get stuck for some reason. Not sure if you ever heard that happening before?

I've heard a few reports similar to this from three.js users, but most of those reports have not been reproducible on my iOS devices. If you have examples to share please feel free to file an issue on three.js as well. One exception would be mrdoob/three.js#22445 – using multiple DRACOLoader instances at the same time may cause issues (in addition to allocating more Web Workers than is good for performance and memory) so it's better to reuse the same DRACOLoader instance or dispose of old ones.

@donmccurdy I keep running into this problem so I'll try to make something reproducible and share

[ffdead]

mrdoob/three.js#22445

Actually, maybe this is related. We use useGLTF from drei, and it seems that it creates a new DRACOLoader instance every time we use the hook: https://github.com/pmndrs/drei/blob/master/src/core/useGLTF.tsx

I opened a bug report in Drei: pmndrs/drei#615

[donmccurdy]

I've just started seeing a similar issue again, for applications not pinned to v1.4.x. Filed a new issue at #819.

[tomfinegan]

I suspect this is the same situation as previously: use the pinned decoders to avoid the issue.

Is this problem happening on pages pinned to the new releases?

[donmccurdy]

Not seeing the issue for pages pinned to specific releases — agreed it's likely the same cause.