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.
Description
emsdk_env.batto set up the PATHwebgl/encoder/README.mdThe result will be the
basis_encoder.jsandwasmfiles, attached here for reference:basis_encoder-build.zip
/webgldirectory with a local serverhttp://localhost:..../encode_test/UASTCcheck boxThe console shows
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_FLAGSin theCMakeLists.txtto include theSTACK_SIZElike 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
10MBmight be more appropriate), I can create a corresponding PR.