Cannot read properties of undefined (reading 'getParameter') since 3.1.70 (WebGL)

[FloRecisio]

Hello! Since the version 3.1.70, we have an error at runtime when starting our application using Emscripten and Electron. It worked fine in 3.1.69, I tried to find a commit related to our problem but couldn't find it, so maybe you'll have an idea.
Here is the diff : https://github.com/emscripten-core/emscripten/compare/0486179..12cedf4
If needed, I could test each commit dicotomically, but that would take a lot of time.
The problem is still here in the latest tot version.

Version of emscripten/emsdk with the problem (first and latest):

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.70 (b53978ee3f540dc74761eba127aa7f1b8761a125)
clang version 20.0.0git (https:/github.com/llvm/llvm-project f52b89561f2d929c0c6f37fd818229fbcad3b26c)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\git\emsdk\upstream\bin

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.72-git (ffeb76137e765a0023de2635420a4827ca15106d)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 31af00fda73df8e85e30c71f66e096d486ec8c8b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\git\emsdk\upstream\bin
Build config: +assertions

The error is :

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'getParameter')
    at emscriptenWebGLGet (MyProject.js:10167:24)
    at _glGetIntegerv (MyProject.js:10295:66)
    at imports.<computed> (MyProject.js:6825:20)
    at MyProject.wasm._do_call (MyProject.wasm:0x2b87f34)
    at MyProject.wasm.em_task_queue_execute (MyProject.wasm:0x2b82a89)
    at MyProject.wasm.receive_notification (MyProject.wasm:0x2b83a15)
    at MyProject.wasm.em_task_queue_execute (MyProject.wasm:0x2b82a89)
    at MyProject.wasm._emscripten_check_mailbox (MyProject.wasm:0x2b9df0c)
    at ret.<computed> (MyProject.js:6851:20)
    at MyProject.js:1078:12

The generated js :

   case 33307:
   // GL_MAJOR_VERSION
    case 33308:
    // GL_MINOR_VERSION
    if (GL.currentContext.version < 2) {
      GL.recordError(1280);
      // GL_INVALID_ENUM
      return;
    }
    ret = name_ == 33307 ? 3 : 0;
    // return version 3.0
    break;
  }
  if (ret === undefined) {
    var result = GLctx.getParameter(name_);               <==== getParameter is undefined 
    switch (typeof result) {
     case "number":
      ret = result;
      break;

     case "boolean":
      ret = result ? 1 : 0;
      break;

Some command

target_compile_options(MyProject
    PUBLIC
        -g
        -fdebug-compilation-dir='${PROJECT_SOURCE_DIR}/src'
        -fexceptions
        -flto
)

target_link_options(MyProject
    PUBLIC
        -lembind
        --no-heap-copy
        --preload-file=${CMAKE_BINARY_DIR}/assets.zip@assets.zip
        -pthread
        -fexceptions

        -sSTRICT=1

        -sNO_EXIT_RUNTIME=1
        -sALLOW_MEMORY_GROWTH=1

        -sABORTING_MALLOC=0

        -sASSERTIONS=1
        -g

        -sEXPORT_ALL=1
        -sAUTO_JS_LIBRARIES=1
        -sAUTO_NATIVE_LIBRARIES=1
        -sFETCH=1

        -sWASM=1

        -sPTHREAD_POOL_SIZE=10
        -sEXPORTED_RUNTIME_METHODS=ccall,UTF8ToString,HEAPU32,HEAPF32
        -sINCOMING_MODULE_JS_API=locateFile,preRun,print,printErr,wasmMemory,buffer,instantiateWasm,wasm,onAbort

        -sAUDIO_WORKLET=1
        -sWASM_WORKERS=1
        -sASYNCIFY

        -sOFFSCREEN_FRAMEBUFFER=1
        -sOFFSCREENCANVAS_SUPPORT=1

        -sTEXTDECODER=0
)

Thanks for your help :)

[kripken]

If needed, I could test each commit dicotomically, but that would take a lot of time.

Bisection is a good option here, it should take a small number of steps. See the docs here:

https://emscripten.org/docs/contributing/developers_guide.html#bisecting

[sbc100]

There were a few changes related to WASM_WORKERS and AUDIO_WORKLET in that range. Things like #22721 and #22731.

Hopefully bisection will give is the precise information we need. Is there a way you can build your project without WASM_WORKERS and AUDIO_WORKLET to confirm its worker related?

[FloRecisio]

Thanks for your answers! I didn't know it was possible to use the install command with a commit hash from the emscripten-releases repository.

I found the commit which break our project:

Ok

install d480b01967481f93a9b22d7135483acc00e82399
Date: Monday, October 21, 2024 9:17:40 PM
Roll llvm-project from 8ae39c8e34de to 74e1554d7b40 (24 revisions)

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.70-git (4cb7739d26b95e9dd3b1f0f40e77fef6ddaedc07)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 74e1554d7b4013a975cf5fb8df64a6419bb14a45)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\git\emsdk\upstream\bin
Build config: +assertions

Broken

install d542ad35dad92f276ba6a7030b1d75cc883e0e80
Date: Monday, October 21, 2024 9:51:34 PM
Roll emscripten from 4cb7739d26b9 to 8cce4db332a3 (1 revision)

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.70-git (8cce4db332a325b770d2d36c3dd89a41b7f11f7c)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 74e1554d7b4013a975cf5fb8df64a6419bb14a45)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\git\emsdk\upstream\bin
Build config: +assertions

The PR #22542 seems to introduce this bug, although it may not seem obvious...

[sbc100]

#22542 seems like an unlikely candidate for this type of breakage. Can you double check?

It seems like the issue is that GLctx is not set during a call to glGetIntegerv. Can you perhaps add some assertion at the point were you create the GL context? What API do you use for this?

[FloRecisio]

I have double-checked and I can confirm that it's indeed #22542 that introduces our problem. However, after investigation, I think that the problem relates to pthread rather than webgl. Our webgl implementation is strongly inspired by this test: the context is created in a pthread, followed by the gl calls.

I did a diff of the generated js:

[...]
Module["spawnThread"] = spawnThread;

var runtimeKeepaliveCounter = 0;
Module["runtimeKeepaliveCounter"] = runtimeKeepaliveCounter;
var keepRuntimeAlive = () => runtimeKeepaliveCounter > 0;

Module["keepRuntimeAlive"] = keepRuntimeAlive;
[...]

becomes

[...]
Module["spawnThread"] = spawnThread;

var keepRuntimeAlive = () => !ENVIRONMENT_IS_PTHREAD;

Module["keepRuntimeAlive"] = keepRuntimeAlive;
[...]

and below:

[...]
Module["getValue"] = getValue;

var invokeEntryPoint = (ptr, arg) => {
[...]

becomes

[...]
Module["getValue"] = getValue;

var runtimeKeepaliveCounter = 0;
Module["runtimeKeepaliveCounter"] = runtimeKeepaliveCounter;

var invokeEntryPoint = (ptr, arg) => {
[...]

Interesting fact: if I replace

var keepRuntimeAlive = () => !ENVIRONMENT_IS_PTHREAD;

with

var keepRuntimeAlive = () => true;

the error disappears and our application works.

I also replaced -sNO_EXIT_RUNTIME=1 with -sEXIT_RUNTIME=0 for simplicity in our config (this doesn't change anything obvisouly).

[sbc100]

I have double-checked and I can confirm that it's indeed #22542 that introduces our problem. However, after investigation, I think that the problem relates to pthread rather than webgl. Our webgl implementation is strongly inspired by this test: the context is created in a pthread, followed by the gl calls.

Does you thread return from its main entry point and expect the runtime to stay alive? Or is just a normal blocking pthread entry point that exists the thread when it returns?

[sbc100]

If you build with -sRUNTIME_DEBUG or -sPTHREADS_DEBUG do you see your thread exiting early perhaps?

[FloRecisio]

Indeed, as I understand, the thread seems to exit early. Our code looks like:

int main()
{
	emscripten_set_main_loop(mainloop, 0, true);
	return 0; // Never reached (tested with a log)
}

The main loop seems ok, I have these warnings in the console after calling emscripten_set_main_loop

runtimeKeepalivePush -> counter=1
handleException: unwinding: EXITSTATUS=0

And after, mainloop is infinitly called, with this warning at each loop. In our application the mainloop does nothing anyway.

maybeExit: user callback done: runtimeKeepaliveCounter=1

Later, this is called from the js (outside of the c++ code, from the electron app):

void init_canvas(const std::string& canvasId)
{
        [...]
        pthread_attr_t threadAttributes;
        pthread_attr_init(&threadAttributes);
        emscripten_pthread_attr_settransferredcanvases(&threadAttributes, canvasId.c_str());
        
        pthread_t* thread = new pthread_t;
        context->thread = thread; // We hold the thread in a context
        pthread_create(thread, &threadAttributes, &render_thread, (void*)context);
        pthread_attr_destroy(&threadAttributes);
        // Return with no problem
}

void* render_thread(void* argv)
{
	RenderContext* renderContext = static_cast<RenderContext*>(argv);
	// WebGL context is created here
	emscripten_set_main_loop_arg(render_loop, renderContext, 0, true);
	return nullptr; // Never reached (tested with a log)
}

init_canvas and then render_thread are properly called.
When emscripten_set_main_loop_arg is called, we have these errors logs:

runtimeKeepalivePush -> counter=1
worker: Pthread 0x2ddac00 (render_thread) completed its main entry point with an 'unwind', keeping the worker alive for asynchronous operation.

Then render_loop is called once, I can see my begin and end logs. Also, I can notice that a frame is commited on the canvas (I see it). When render_loop return, we have these errors logs:

maybeExit: user callback done: runtimeKeepaliveCounter=1
maybeExit: calling exit() implicitly after user callback completed: undefined

And then render_loop() is called again, and the error "Cannot read properties of undefined (reading 'getParameter')" occurs, I guess because the thread exited after the first loop... But I don't understand how render_loop can be called a second time if pthread exited?

If it can help, maybe I can write a simple test and reproduce this case?

[sbc100]

And after, mainloop is infinitly called, with this warning at each loop. In our application the mainloop does nothing anyway.

Unrelated to this specific issue but if you don't need the main thread loop to do anything then you can just call emscripten_exit_with_live_runtime() rather then creating an emscripten-level event loop. In fact I think you can simply return from the main function (since you are building with NO_EXIT_RUNTIME the runtime will stay alive in any case).

The advantage of doing this is that your main thread will be less busy. it will still respond to requests from worker threads but it won't run its own loop code.

[sbc100]

maybeExit: user callback done: runtimeKeepaliveCounter=1
maybeExit: calling exit() implicitly after user callback completed: undefined

This seems like it must be the problem. Can you tell if this is coming from the main thread or from the worker?

If you have runtimeKeepaliveCounter at all in your program then I think the simple definition of maybeExit must be wrong

[sbc100]

one thing I don't get its why the thread exiting would cause the GLctx on the main thread to become undefined. Do you know why that might be? Its like the context is shut down somewhere/somehow?

[FloRecisio]

This seems like it must be the problem. Can you tell if this is coming from the main thread or from the worker?

I don't know if I can get precise information about which thread called the logs, but from my understanding they are called from the worker. In my example, just after render_loop exited, I guess from the same worker under the hood.

If you have runtimeKeepaliveCounter at all in your program then I think the simple definition of maybeExit must be wrong

I don't understand your point sorry, what are you thinking?

one thing I don't get its why the thread exiting would cause the GLctx on the main thread to become undefined. Do you know why that might be? Its like the context is shut down somewhere/somehow?

I checked earlier and I have disabled all our code that could possibly kill this loop and the context from the outside. However, if I understand correctly, the gl context is created from the thread where the render_loop function is set up, and this thread seems to prematurely exit when render_loop return the first time. What I don't understand is that render_loop is called a second time, but this time the first gl call fails. Perhaps because the thread has exited in an undefined state, the memory is corrupted? I have no idea.

I'm going to try and simplify our code to understand what's going on, and perhaps make a very simple test that you can reproduce.

[sbc100]

This seems like a bug on the emscripten side. The definition of keepRuntimeAlive should include runtimeKeepaliveCounter.

BTW, does the maybeExit tracing not include the pthread and worker ID as a prefix to the message? In pthread builds all dbg messsages should be prefixed with this info.