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

RuntimeError when encoding to UASTC with WASM #356

Open
javagl opened this issue Sep 5, 2023 · 1 comment
Open

RuntimeError when encoding to UASTC with WASM #356

javagl opened this issue Sep 5, 2023 · 1 comment

Comments

@javagl
Copy link

javagl commented Sep 5, 2023

Description

  • Windows Version 10.0
  • Clone the current state (this commit at the time of writing this)
  • Clone the current emsdk (this commit at the time of writing this)
  • Use LLVM version 12.0.0 (if that matters)
  • Run the emsdk_env.bat to set up the PATH
  • Compile the encoder, as described in the webgl/encoder/README.md
    The result will be the basis_encoder.js and wasm files, attached here for reference:
    basis_encoder-build.zip
  • Serve the /webgl directory with a local server
  • Visit http://localhost:..../encode_test/
  • Select the UASTC check box
  • Hit 'Encode!'

The console shows

basis_encoder.wasm:0x36da2 Uncaught RuntimeError: memory access out of bounds
    at basis_encoder.wasm:0x36da2
    at basis_encoder.wasm:0x282a3
    at basis_encoder.wasm:0x14223
    at basis_encoder.wasm:0xb0c
    at basis_encoder.wasm:0xd7983
    at basis_encoder.wasm:0xd72a5
    at ClassHandle.BasisFile$getFileDesc [as getFileDesc] (eval at newFunc (basis_encoder.js:8:81985), <anonymous>:8:10)
    at dumpBasisFileDesc ((index):160:33)
    at dataLoaded ((index):230:3)
    at PNGDataLoaded ((index):471:3)

This happens on Chrome 116.0 and FireFox 117.0, and the same error appears when using the build output in Node.js, so it seems to be a general issue.

Possible solution

After a bunch of trial and error, I stumbled over emscripten-core/emscripten#19268 (comment) , and after changing the LINK_FLAGS in the CMakeLists.txt to include the STACK_SIZE like this...

LINK_FLAGS "--bind -s ALLOW_MEMORY_GROWTH=1 -O3 -s ASSERTIONS=0 -s INITIAL_MEMORY=299958272 -s MALLOC=emmalloc -s MODULARIZE=1 -s EXPORT_NAME=BASIS -s STACK_SIZE=10MB")

... the problem no longer appears.

If others confirm that this makes sense (or add details, like which other size than 10MB might be more appropriate), I can create a corresponding PR.

@richgel999
Copy link
Contributor

Hmm - that's a lot of stack, and this didn't happen before in my testing. I will investigate this. Thanks for the filing the issue.

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

2 participants