-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Uncaught TypeError: Failed to execute 'uniform4fv' on 'WebGL2RenderingContext': Overload resolution failed. #21567
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
Comments
Seems to happen when the count argument to glUniform4fv is 0. |
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 |
Here's the JS file function:
link flags:
|
printing out stuff to the console, it looks like 'view' is undefined just before the GLctx.uniform4fv call. |
Am not going to do any version bisection sorry :) |
Thank you for the information. I think that should provide enough info to debug further. |
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. |
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
great :) |
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
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
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
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
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
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
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
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
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
The text was updated successfully, but these errors were encountered: