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

Uncaught TypeError: Failed to execute 'uniform4fv' on 'WebGL2RenderingContext': Overload resolution failed. #21567

Closed
Ono-Sendai opened this issue Mar 20, 2024 · 9 comments · Fixed by #21573

Comments

@Ono-Sendai
Copy link

Hi,
I updated EmSDK to the latest version (3.1.56), and now am hitting the following error while executing my WASM program:

gui_client.js:11877 Uncaught TypeError: Failed to execute 'uniform4fv' on 'WebGL2RenderingContext': Overload resolution failed. at _glUniform4fv (gui_client.js:11877:8)

EmSDK version:

Resolving SDK version '3.1.56' to 'sdk-releases-9d106be887796484c4aaffc9dc45f48a8810f336-64bit'
Installing SDK 'sdk-releases-9d106be887796484c4aaffc9dc45f48a8810f336-64bit'..

It worked fine before updating.

Cheers,
Nick

@Ono-Sendai
Copy link
Author

Seems to happen when the count argument to glUniform4fv is 0.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 20, 2024

Could you share the full set of link flags you are using?

Can you confirm that this doesn't happen in 3.1.55? Perhaps you could help track down the exact change that caused this failure by bisecting: https://emscripten.org/docs/contributing/developers_guide.html#bisecting

Finally perhaps you could shared what is on line 11877 of your JS file? How many arguments are being passed to uniform4fv and maybe you could console.error(arguments) and report the types you see?

@Ono-Sendai
Copy link
Author

Here's the JS file function:

/** @suppress {duplicate } */ function _glUniform4fv(location, count, value) {
 value >>>= 0;
 if (count <= 72) {
  var view = miniTempWebGLFloatBuffers[4 * count - 1];
  var heap = HEAPF32;
  value = ((value) >>> 2);
  for (var i = 0; i < 4 * count; i += 4) {
   var dst = value + i;
   view[i] = heap[dst >>> 0];
   view[i + 1] = heap[dst + 1 >>> 0];
   view[i + 2] = heap[dst + 2 >>> 0];
   view[i + 3] = heap[dst + 3 >>> 0];
  }
 } else {
  var view = HEAPF32.subarray((((value) >>> 2)) >>> 0, ((value + count * 16) >>> 2) >>> 0);
 }
 GLctx.uniform4fv(webglGetUniformLocation(location), view);
}

link flags:

[1/1] cmd.exe /C "cd . && C:\programming\emsdk\upstream\emscripten\em++.bat -I"c:/programming/libjpeg-turbo/libjpeg-turbo-emscripten-build/include" -I"c:/code/glare-core/libpng" -I"c:/code/glare-core/pugixml/src" -I"c:/code/glare-core/zlib" -I"c:/code/glare-core/Imath/src/Imath" -I"c:/code/glare-core/OpenEXR/src/lib/Iex" -I"c:/code/glare-core/OpenEXR/src/lib/IlmThread" -I"c:/code/glare-core/OpenEXR/src/lib/OpenEXR" -I"c:/code/glare-core/OpenEXR/src/lib/OpenEXRUtil" -I"c:/code/glare-core/Imath/config_linux" -I"c:/code/glare-core/OpenEXR/config_linux" -I"c:/code/glare-core/" -I"c:/code/glare-core/utils" -I"c:/code/glare-core/networking" -I"c:/code/glare-core/maths" -I"c:/code/glare-core/opengl" -I"c:/code/glare-core/giflib/lib" -I"c:/code/glare-core/little_cms/include" -I"c:/code/glare-core/zstd/lib" -I"c:/code/glare-core/zstd/lib/common" -I"c:/code/glare-core/opencl/khronos" -I"c:/programming/BugSplat/BugSplat/inc" -Ic:/programming/llvm/llvm_15_0_7_dylib_install/include -I/usr/local/include -Ic:/programming/LibreSSL/libressl-3.5.2-install/include -O2 -g -DNDEBUG   -O2 -g -DNDEBUG -DBUILD_TESTS=1 "-s USE_WEBGL=1" -sMIN_WEBGL_VERSION=2 -sMAX_WEBGL_VERSION=2 -sGL_ENABLE_GET_PROC_ADDRESS -fwasm-exceptions -sINITIAL_MEMORY=3500MB -pthread -sPTHREAD_POOL_SIZE=26 -sSTACK_SIZE=262144 -lwebsocket.js --preload-file data @CMakeFiles\gui_client.rsp -o C:\programming\cyberspace\output\test_builds\gui_client.js  && cd ."

@Ono-Sendai
Copy link
Author

printing out stuff to the console, it looks like 'view' is undefined just before the GLctx.uniform4fv call.
I guess this is due to var view = miniTempWebGLFloatBuffers[4 * count - 1]; when count is zero.

@Ono-Sendai
Copy link
Author

Am not going to do any version bisection sorry :)

@sbc100
Copy link
Collaborator

sbc100 commented Mar 20, 2024

Thank you for the information. I think that should provide enough info to debug further.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 20, 2024

It looks like this was originally fixed in #16837, but the fix didn't cover the path when WEBGL_USE_GARBAGE_FREE_APIS was not available.

sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 20, 2024
The previous fix for this was in emscripten-core#21567, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

Fixes: emscripten-core#21567
@sbc100
Copy link
Collaborator

sbc100 commented Mar 20, 2024

I tracked it down.

This was originally reported in #16799, partially fixed in #16837, then exposed again with #21445 (although it continued to exist for webgl1 users). Latest fix is now in #21573

@Ono-Sendai
Copy link
Author

great :)

sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 20, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 20, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 20, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 20, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

As part of this change I resurrected
`test_webgl_draw_triangle_with_uniform_color.c` which has not actually
be used since emscripten-core#20925.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 21, 2024
As part of this change I resurrected
`test_webgl_draw_triangle_with_uniform_color.c` which has not actually
be used since emscripten-core#20925.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 21, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.

As part of this change I resurrected
`test_webgl_draw_triangle_with_uniform_color.c` which has not actually
be used since emscripten-core#20925.

Fixes: emscripten-core#21567
sbc100 added a commit to sbc100/emscripten that referenced this issue Mar 21, 2024
The previous fix for this was in emscripten-core#16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.

As part of this change I resurrected
`test_webgl_draw_triangle_with_uniform_color.c` which has not actually
be used since emscripten-core#20925.

Fixes: emscripten-core#21567
sbc100 added a commit that referenced this issue Mar 26, 2024
The previous fix for this was in #16837, but I looks like that only
covered the new "garbage-free" webgl2 path.  When old webgl1 path was
still using the zero count value.  For example the following line was
unguarded:

```
var view = miniTempWebGLFloatBuffers[4 * count - 1];
```

This recently resurfaced because I introduced
`WEBGL_USE_GARBAGE_FREE_APIS` which is currently disabled for memories
larger 2gb.  This meant that users with large memories were forces onto
the old path where the bug still existed.

Rather than adding yet more `count &&` prefixes, this patch simply adds
a single early return at the top of each function.

As part of this change I resurrected
`test_webgl_draw_triangle_with_uniform_color.c` which has not actually
be used since #20925.

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

Successfully merging a pull request may close this issue.

2 participants