Intermittent load error for meshes on Android Chrome 91

Hi, when attempting to load this playground on my Android device running Chrome 91 (currently the latest). I am coming across an error intermittently, around 1/5 of the time:
“{mesh path}/model.gltf /meshes/72/primitives/0: Uncaught RuntimeError: function signature mismatch”

The error is reproducible here: https://playground.babylonjs.com/#CQEEKE#10

Currently retrying seems like a good workaround but I would like insight into what is occurring here. If there are any similar issues/suggestions I would love to hear them.

@bghgary might have an idea ?

Hmm, I ran it twice on my Android phone just now. It worked the first time. The second time, it has an error:

Unable to load from <path>/model.gltf: /meshes/24/primitives/0: Uncaught RuntimeError: table index is out of bounds

This seems to repro very often (>50%) for me.

I got the function signature mismatch also now. It seems to always be mesh 24 (for me) which is curious. Also, this is probably an error from Draco decompression.

1 Like

I think maybe we are running out of memory?

Uncaught RuntimeError: table index is out of bounds
    at emscripten_bind_PointCloud___destroy___0 (<anonymous>:wasm-function[77]:0x9000)
    at a._emscripten_bind_Mesh___destroy___0 (preview.babylonjs.com/draco_wasm_wrapper_gltf.js:58)
    at y.__destroy__.y.__destroy__ (preview.babylonjs.com/draco_wasm_wrapper_gltf.js:101)
    at Object.a.destroy (preview.babylonjs.com/draco_wasm_wrapper_gltf.js:74)
    at vp (blob:https://playground.babylonjs.com/69721a14-828c-40f5-980e-a30fb957050f:1)
    at blob:https://playground.babylonjs.com/69721a14-828c-40f5-980e-a30fb957050f:1
    at Object.a.then (preview.babylonjs.com/draco_wasm_wrapper_gltf.js:72)
    at onmessage (blob:https://playground.babylonjs.com/69721a14-828c-40f5-980e-a30fb957050f:1)
12000be69e:0x2a91f Uncaught RuntimeError: memory access out of bounds
    at malloc (<anonymous>:wasm-function[622]:0x2a91f)
    at <anonymous>:wasm-function[582]:0x29c35
    at emscripten_bind_DecoderBuffer_DecoderBuffer_0 (<anonymous>:wasm-function[114]:0x930e)
    at a._emscripten_bind_DecoderBuffer_DecoderBuffer_0 (draco_wasm_wrapper_gltf.js:49)
    at new K (draco_wasm_wrapper_gltf.js:19)
    at vp (69721a14-828c-40f5-980e-a30fb957050f:1)
    at 69721a14-828c-40f5-980e-a30fb957050f:1
    at Object.a.then (draco_wasm_wrapper_gltf.js:72)
    at onmessage (69721a14-828c-40f5-980e-a30fb957050f:1)
3 Likes

What’s interesting is that it doesn’t appear to be an issue with older versions of Android Chrome. For instance, Browserstack is on v89 and we can’t reproduce the issue there. It’s only Android Chrome v91.

Weird. That’s interesting.

Just for kicks, I tried to repro in Edge and it doesn’t repro. Edge is probably on an older version of Chromium compared to Chrome, which supports that it only happens on a recent version.

1 Like

I’m not really sure how to diagnose this further. It seems like we need to either ask the Draco team or Chromium team.

2 Likes

Do you guys have any contacts over there? In the meantime we’re trying different Draco settings.

It’s already been reported and investigated apparently. :slight_smile:

‘Table index is out of bounds’ and ‘Memory access out of bounds’ on Android Chrome · Issue #726 · google/draco (github.com)

2 Likes

We’re going to try some things with our Draco settings and then re-assess. I saw people discussing drastic solves like disabling the WASM for Android and falling back to JS to decode. Yikes.

You can try the workaround versions as noted in the issue. https://www.gstatic.com/draco/versioned/decoders/1.4.2/

2 Likes