Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3.3.2 HTML5 Regular export not stable on mobile browsers, WASM crash on page reload, cowdata.h:142:set() - FATAL: Index p_index = 0 is out of bounds #49797

Closed
lukaelb opened this issue Jun 21, 2021 · 18 comments

Comments

@lukaelb
Copy link

lukaelb commented Jun 21, 2021

Godot version

v3.3.2.stable.official

System information

Windows 10, GLES2, issues reproduced on Android, Google Chrome and Webinspector

Issue description

HTML5 export, default export templates, desktop works fine but I can't get it to work stable on mobile browsers. First load will work, but once page is reloaded a few times, the error below will print in console and "unreachable" will be shown instead of the game. In order to open the game again, it must be done on another tab. Clearing cookies doesn't help. Once the issue happens on a single tab, no matter how many times page is reloaded, game will not load, it will keep saying "unreachable" and error below will be shown in console. I tried serving with disabled caching as well, and saw 200 response on each request but same issues were still happening.

--------------------
**ERROR**: FATAL: Index p_index = 0 is out of bounds (size() = 0).
--------------------
   At: ./core/cowdata.h:142:set() - FATAL: Index p_index = 0 is out of bounds (size() = 0).
--------------------
exception thrown: RuntimeError: unreachable,RuntimeError: unreachable
    at <anonymous>:wasm-function[47963]:0x9da0b2
    at <anonymous>:wasm-function[47958]:0x9d9ece
    at <anonymous>:wasm-function[29104]:0x53a31f
    at <anonymous>:wasm-function[33748]:0x75366d
    at <anonymous>:wasm-function[20777]:0x38fc87
    at <anonymous>:wasm-function[43093]:0x8a381d
    at _j (<anonymous>:wasm-function[16693]:0x2cd806)
    at $j (<anonymous>:wasm-function[27629]:0x4caa5e)
    at Module._main (http://192.168.2.14/index.js:9:331320)
    at Object.callMain (http://192.168.2.14/index.js:9:336232)
--------------------
unreachable
--------------------

issue with similar behaviour can be reproduced when Script Export Mode is set to Compile or when game is exported as Debug but error will include "function signature mismatch" without much more info, same is displayed instead of the game. Snippet below is with Debug Export and Compiled Script Export Mode

--------------------
exception thrown: RuntimeError: function signature mismatch,RuntimeError: function signature mismatch
    at godot_js_main(int, char**) (<anonymous>:wasm-function[11302]:0x21d83b)
    at main (<anonymous>:wasm-function[23629]:0x58e715)
    at Module._main (http://192.168.2.14/index.js:9:331562)
    at Object.callMain (http://192.168.2.14/index.js:9:336474)
    at http://192.168.2.14/index.js:684:28
    at new Promise (<anonymous>)
    at http://192.168.2.14/index.js:679:14
--------------------
function signature mismatch
--------------------

I think that it's easier to reproduce on a faster phone. I might be totally wrong on this and it might be my specific use case, but few slower test phones I have play the game way better than my POCO X3 PRO (Snapdragon 860, Adreno 640). Issue is reproduced just fine on galaxy s9 as well. The issue could possibly have something to do with the fact that page loads quick, but I might be totally wrong on this.

Steps to reproduce

  1. Create an empty project
  2. add Node2D
  3. save current scene
  4. play scene
  5. follow prompt to make the saved scene the main scene
  6. make sure game runs in editor
  7. Add HTML5 export, download export templates when prompted if needed
  8. Apply following settings -> Options tab -> Regular Export Type Variant; Script tab -> Text Script Export Mode
  9. Export without debug (exporting with debug will result in same behaviour but different error without much info, but containing "function signature mismatch")
  10. create export dir and export project as index.html in that export dir.
  11. serve the export directory (containing index.html) your preferred way (quick way I use (python or python3): python -m http.server --bind 0.0.0.0 80 )
  12. check your local ip your preferred way (for example ifconfig in cmd or ipconfig in terminal)
  13. visit via google chrome and use remote debugging to see console logs or use app like Webinspector to access the game and the see console logs in the app.
  14. reload the page few times

Minimal reproduction project

bugrepro.zip

@lukaelb lukaelb changed the title HTML5 Regular export not stable on mobile browsers, WASM crash on page reload, cowdata.h:142:set() - FATAL: Index p_index = 0 is out of bounds v3.3.2 HTML5 Regular export not stable on mobile browsers, WASM crash on page reload, cowdata.h:142:set() - FATAL: Index p_index = 0 is out of bounds Jun 21, 2021
@Calinou
Copy link
Member

Calinou commented Jun 21, 2021

cc @Faless

@lukaelb
Copy link
Author

lukaelb commented Jun 21, 2021

I'm added a bunch of logs in the exported .js file(index.js in my case), this is where the logs stop and where the issue happens:
me.rtenv['callMain'](me.config.args);

@Zireael07
Copy link
Contributor

AFAICT most mobile browsers have this problem and this is not something specific to Godot - IIRC Endless Sky WASM port had that issue and so did macroquad (a Rust graphics library).

It might be something to do with the fact WASM can and will try to access memory you physically don't have (and mobile browsers are bad at letting memory go after a reload)

@Faless
Copy link
Collaborator

Faless commented Jun 21, 2021 via email

@poly-games
Copy link

If the page works at first, then reloading does not, it's likely a browser bug. I've experienced "function signature mismatch" on reload on chrome for Android (but not Firefox). So again, likely a chrome bug. If it was a Godot bug, it should not work the first time. Might be worth opening an issue on the chromium repository.

On Mon, Jun 21, 2021, 16:04 Zireael07 @.***> wrote: AFAICT most mobile browsers have this problem and this is not something specific to Godot - IIRC Endless Sky WASM port had that issue and so did macroquad (a Rust graphics library). It might be something to do with the fact WASM can and will try to access memory you physically don't have (and mobile browsers are bad at letting memory go after a reload) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49797 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM4C3SPKXWBA3QPYBNWEQDTT5BH3ANCNFSM47BRVX5Q .

The error is repeated across browsers and client applications, where other game engines feel great. In addition, the problem is specific to Godot version 3.3.x

@Calinou
Copy link
Member

Calinou commented Jun 21, 2021

This is likely a regression from #46731, judging by other issue reports I've seen.

@lukaelb
Copy link
Author

lukaelb commented Jun 22, 2021

@Faless It happens across devices and browsers, it is not a chromium only issue.

@Zireael07 @poly-games @Calinou do we know any workarounds for this issue? Are you aware of any attempt on debugging this or similar issues, I do believe I saw similar issues around, kws "unreachable" and "function signature mismatch". Possible downgrade to version before #46731 is out of options since we lose wasm support.

Any ideas are greatly appreciated. Could reverting #46731 and recompiling work? What would be the best way of thinking and course of action to try resolve this?

@Calinou
Copy link
Member

Calinou commented Jun 22, 2021

Possible downgrade to version before #46731 is out of options since we lose wasm support.

WebAssembly has been supported since Godot 3.0.

Any ideas are greatly appreciated. Could reverting #46731 and recompiling work? What would be the best way of thinking and course of action to try resolve this?

There are a lot of merge conflicts that make this not viable, unfortunately.

git clone https://github.com/godotengine/godot.git
git checkout 3.3.2-stable
git revert -m1 82fcd3a7b8932908abc1c774979186c4adce861e
# Lots of difficult-to-resolve merge conflicts.

@Zireael07
Copy link
Contributor

I don't know any workarounds, and some googling seems to show most people's answer is: "we don't recommend mobile browsers"

Some links: pingcap/tidb#13322 brave/brave-browser#3366

(The exact error raised is different though, so it might be indeed a dupe of the other issues - IIRC those showed up after an Emscripten upgrade?)

@lukaelb
Copy link
Author

lukaelb commented Jun 22, 2021

@Calinou thanks!

As comment from @poly-games suggests, 3.2.stable does not appear to suffer from this issue.

I just exported the same project in 3.2.stable and am unable to reproduce this issue. Reloaded page 10x , game loads just fine every time, noticeably faster than on 3.3 as well.

@Faless

@poly-games
Copy link

@Calinou thanks!

As comment from @poly-games suggests, 3.2.stable does not appear to suffer from this issue.

I just exported the same project in 3.2.stable and am unable to reproduce this issue. Reloaded page 10x , game loads just fine every time, noticeably faster than on 3.3 as well.

@Faless

Exporting from 3.2 stable helps for 6 out of 7 of my games (the seventh shows an error "memory access out of bounds"), but after loading, a black screen appears for a few seconds. I am looking for a solution to how I can replace this black screen with the game loading screen so as not to scare away potential players.

@Faless
Copy link
Collaborator

Faless commented Jun 22, 2021

The error is repeated across browsers and client applications

@poly-games So... it also happens on Firefox for Android? Because the OP only mentioned Chrome for Android, and in my experience I've only seen it in Chrome (or Chromium based browsers).

EDIT: In which browsers can you confirm the errror?

@Faless
Copy link
Collaborator

Faless commented Jun 22, 2021

See potentially related: https://bugs.chromium.org/p/v8/issues/detail?id=11863
Issue 11863: Wasm memory growth causes heap corruption

@lukaelb
Copy link
Author

lukaelb commented Jun 23, 2021

See potentially related: https://bugs.chromium.org/p/v8/issues/detail?id=11863
Issue 11863: Wasm memory growth causes heap corruption

The error is repeated across browsers and client applications

@poly-games So... it also happens on Firefox for Android? Because the OP only mentioned Chrome for Android, and in my experience I've only seen it in Chrome (or Chromium based browsers).

EDIT: In which browsers can you confirm the errror?

I'm citing these as I'm trying them out, I don't know what they use under the hood, the problematic ones could or might not be using exactly chromium under the hood.

Webinspector - ISSUE REPRODUCED
Chrome - ISSUE REPRODUCED
DuckDuckGo - ISSUE REPRODUCED
Brave - ISSUE REPRODUCED
Firefox - UNABLE TO REPRODUCE, WORKS FINE
Opera - UNABLE TO REPRODUCE
Edge - not this particular issue but after switching back to the app after testing others, I got "WebGL lost context"

edit: still would like to note again, exporting same project with 3.2 removes the issue for my project on chrome.

@Faless
Copy link
Collaborator

Faless commented Jun 23, 2021

Webinspector - ISSUE REPRODUCED
Chrome - ISSUE REPRODUCED
DuckDuckGo - ISSUE REPRODUCED
Brave - ISSUE REPRODUCED

Indeed, those are all chromium based browsers.

exporting same project with 3.2 removes the issue for my project on chrome.

Yes, potentially 3.3 does something that triggers the memory corruption in the browser.
But it still seems a browser issue to me. Again, if the first load works. The engine is doing fine.
If reloading does not, it's a browser fault because from the application point of view the first load and the second must be identical. Especially after clearing the cache like mentioned in the OP.

@Faless
Copy link
Collaborator

Faless commented Jul 11, 2021

See also: emscripten-core/emscripten#14538

According to chromium bug tracker this is fixed in Chrome 91.0.4472.114 which hasn't shipped on mobile yet (at least for me). but I tried on mobile with Chrome Beta (92.0.4515.92) and the issue is in fact gone in my tests.

@lukaelb @poly-games can any of you confirm the issue is fixed in Chrome Beta (Chrome 92)?

@Faless
Copy link
Collaborator

Faless commented Jul 21, 2021

This seems fixed in latest Chrome for Android 91.0.4472.164, although the chrome bug status is still open (but the last report is for 91.0.4472.161).

@Calinou
Copy link
Member

Calinou commented May 27, 2022

This is likely fixed by now, so this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants