Crash on WebASM

[TheMostDiligent]

Hello!

I am trying to enable glslang on WebASM (Emscripten) and the build goes well. However, at run time, glslang crashes with the following stack:

Tutorial03_Texturing.html:286 Uncaught RuntimeError: memory access out of bounds
    at Tutorial03_Texturing.wasm.glslang::TScanContext::tokenize(glslang::TPpContext*, glslang::TParserToken&) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[34865]:0xa1614e)
    at Tutorial03_Texturing.wasm.yylex(YYSTYPE*, glslang::TParseContext&) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[34861]:0xa15ef7)
    at Tutorial03_Texturing.wasm.yyparse(glslang::TParseContext*) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[37227]:0xad5a46)
    at Tutorial03_Texturing.wasm.glslang::TParseContext::parseShaderStrings(glslang::TPpContext&, glslang::TInputScanner&, bool) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[37501]:0xb13398)
    at Tutorial03_Texturing.wasm.(anonymous namespace)::InitializeSymbolTable(std::__2::basic_string<char, std::__2::char_traits<char>, glslang::pool_allocator<char>> const&, int, EProfile, glslang::SpvVersion const&, EShLanguage, glslang::EShSource, TInfoSink&, glslang::TSymbolTable&) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40664]:0xc4df2a)
    at Tutorial03_Texturing.wasm.(anonymous namespace)::InitializeSymbolTables(TInfoSink&, glslang::TSymbolTable**, glslang::TSymbolTable**, int, EProfile, glslang::SpvVersion const&, glslang::EShSource) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40652]:0xc4c561)
    at Tutorial03_Texturing.wasm.(anonymous namespace)::SetupBuiltinSymbolTable(int, EProfile, glslang::SpvVersion const&, glslang::EShSource) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40610]:0xc49745)
    at Tutorial03_Texturing.wasm.bool (anonymous namespace)::ProcessDeferred<(anonymous namespace)::DoFullParse>(TCompiler*, char const* const*, int, int const*, char const* const*, char const*, EShOptimizationLevel, TBuiltInResource const*, int, EProfile, bool, int, bool, EShMessages, glslang::TIntermediate&, (anonymous namespace)::DoFullParse&, bool, glslang::TShader::Includer&, std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>, glslang::TEnvironment const*, bool) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40220]:0xc38e60)
    at Tutorial03_Texturing.wasm.(anonymous namespace)::CompileDeferred(TCompiler*, char const* const*, int, int const*, char const* const*, char const*, EShOptimizationLevel, TBuiltInResource const*, int, EProfile, bool, int, bool, EShMessages, glslang::TIntermediate&, glslang::TShader::Includer&, std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>, glslang::TEnvironment*, bool) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40200]:0xc36887)
    at Tutorial03_Texturing.wasm.glslang::TShader::parse(TBuiltInResource const*, int, EProfile, bool, bool, EShMessages, glslang::TShader::Includer&) (wasm://wasm/Tutorial03_Texturing.wasm-17dc23ae:wasm-function[40268]:0xc3bb13)

Also, somehow if I set the ENABLE_GLSLANG_JS=ON (I don't use or need the glslang.js), it starts to work for some shaders, but still crashes for others. I don't understand how this setting may affect other targets.

Could you please suggest what I may be missing?

[TheMostDiligent]

I managed to figured out what was the problem: the default stack size set by Emscripten was insufficient. Increasing the stack size solved the problem:

target_link_options(MyWebApp PRIVATE "SHELL: -s STACK_SIZE=5MB")

[arcady-lunarg]

What was the default stack size being used by emscripten? I would be concerned if glslang is blowing a reasonably sized stack, on the other hand if the default stack is tiny on this one platform, that's not really glslang's problem.

[TheMostDiligent]

What was the default stack size being used by emscripten?

I was not able to find this in the documentation.

I would be concerned if glslang is blowing a reasonably sized stack

glslang.js does not set the stack size. If you only use it for size testing, that is OK. However, compiling complex shaders may overflow the stack as was in our case, so you may consider setting this option too.

[TheMostDiligent]

Found it, the default stack size is 64 Kb.

https://emscripten.org/docs/tools_reference/settings_reference.html?highlight=environment#default-pthread-stack-size

[arcady-lunarg]

Thanks. That really is pretty small, I believe Windows uses 1 MB as the default and Linux uses 2 MB for threads other than the main one, so I would not consider this a glslang issue. If you want to add a note about this to the README section about emscripten, that could be helpful for anyone who runs into this issue in the future.

[TheMostDiligent]

@arcady-lunarg: #3584