NaCl GL ERROR :GL_INVALID_OPERATION - opengl-es-2.0

I am porting a game engine that works perfectly on different platforms (Windows, iOS, Playbook, BB10, Android) to NaCl
2d renders correctly but some 3d Objects don't show or are rendered really strange and i get the following con
[.PPAPIContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : BackTexture::AllocateStorage: <- error from previous GL command (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0 (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type
And it repeats indefinitely.
Again, the same render code is used for different platforms and it works just fine. Is there a special consideration to be taken into account when porting to NaCl? Any ideas about what i should focus on to try find the issue?
As far as i can understand, there's a problem with the shader 0 (the vertex shader) and indeed the vertices of some objects are all over the place.
Thanks! :)

For security reasons, Chrome validates many GL operations that other drivers may not. It's a bit of work, but you might try searching the Chromium codebase using http://cs.chromium.org to find the error messages.
Here's what I found:
BackTexture::AllocateStorage: <- error from previous GL command
This one is tricky to follow. As it says, some previous GL command failed before BackTexture::AllocateStorage was called. I looked through the rest of the file, and it's not clear to me what command is failing here, but from the error value it is framebuffer related.
glVertexAttribPointer: stride not valid for type and glVertexAttribPointer: offset not valid for type
These are pretty clear -- the stride and offset values are not divisible by the component size. It would be useful to see your calls to glVertexAttribPointer.
glDrawElements: attempt to access out of range vertices in attribute 0
VertexAttrib::CanAccess is failing, which checks whether the attrib is enabled, not deleted, and if the vertex index that you're trying to access is valid. As the error says, you are likely referencing a vertex outside of the valid range.
To debug this, I'd narrow down the calls to glDrawElements and glVertexAttribPointer and try to find which one is failing, then I'd add some printf calls to see what values are being passed.
Good luck!

Related

vkQueueSubmit() call includes a stageMask with VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT bit set when device does not have geometryShader feature enabled

First of all, I'm a total newbie with Vulkan (I'm using the binding provided by LWJGL). I know I should copy/paste more code, but I don't even know what would be relevant for now (so don't hesitate to ask me some specific piece of code).
I try to make something like that :
Use a ComputeShader to compute a buffer of pixel.
Use vkCmdCopyBufferToImage to directly copy this array into a framebuffer image.
So, no vertex/fragment shaders for now.
I allocated a Compute Pipeline, and a FrameBuffer. I have one {Queue/CommandPool/CommandBuffer} for Computation, and one other for Rendering.
When I try to submit the graphic queue with:
vkQueueSubmit(graphicQueue, renderPipeline.getFrameSubmission().getSubmitInfo(imageIndex));
I obtain the following error message (from validation) :
ERROR OCCURED: Object: VK_NULL_HANDLE (Type = 0) | vkQueueSubmit() call includes a stageMask with VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT bit set when device does not have geometryShader feature enabled. The spec valid usage text states 'If the geometry shaders feature is not enabled, each element of pWaitDstStageMask must not contain VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubmitInfo-pWaitDstStageMask-00076)
ERROR OCCURED: Object: VK_NULL_HANDLE (Type = 0) | vkQueueSubmit() call includes a stageMask with VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT and/or VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT bit(s) set when device does not have tessellationShader feature enabled. The spec valid usage text states 'If the tessellation shaders feature is not enabled, each element of pWaitDstStageMask must not contain VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT or VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkSubmitInfo-pWaitDstStageMask-00077)
I tried to change the VkSubmitInfo.pWaitDstStageMask to different values (like VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT...) but nothing change.
So, what would be the best pWaitDstStageMask for my use case ?
Ok, I found my problem:
The pWaitDstStageMask must be an array with the same size than pWaitSemaphores.
I only putted 1 stage mask, for 2 semaphores.

Is division by zero considered error or failure?

When my program stops working due to division by 0 then is it considered error or failure?
Error is called when a human action produces an incorrect result. Failure is when we get different result than expected. I'm just wondering if the unexpected stop from program is a error by human or failure of the program?
It is considere as an error. Or we can also called this an exception. And if u dont want to prevent this u can use exception handling.
Depending on the programming environment and the type of number (e.g. floating point, integer) being divided by zero, it may generate positive or negative infinity, generate an exception, generate an error message, cause the program to terminate.
It is a type of failure when it is in compile time but it is an error because usually this type of an error occur when the program is compiled and then executed

3D boolean assertion fail. "mark" not matching

I'm trying to do some 3D boolean operations with CGAL. I have successfully converted my polyhedra to nef polyhedra. However, when ever I try doing a simple union, I get an assertion fail on line 286 of SM_overlayer.h:
CGAL error: assertion violation!
Expression : G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1)
File : ./CGAL/include/CGAL/Nef_S2/SM_overlayer.h
Line : 287
I tried searching the documentation for "mark". Apparently it is a template argument on the Nef_polyhedron_3" that defaults to bool. However the documentation also says it is not implemented and that you shouldn't mess with it. I am a bit confused why there is even an assertion on some unimplemented feature. I tried simply commenting out the assertion, but it simply goes on to fail at a later point.
I am using the following kernel and typedefs as it was the only example I could find that allowed doubles in the construction of the meshes.
typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
typedef CGAL::Nef_polyhedron_3<Kernel> Nef_polyhedron;
typedef CGAL::Polyhedron_3<Kernel> Polyhedron;
I used CGAL 4.6.3 installed with the exe installer. I have also tried the 4.7 beta and I get the same exception(at line 300 instead though).
Related github issue: https://github.com/CGAL/cgal/issues/353
EDIT: The issue turned out to be with the meshes. The meshes I were using had self intersections. Thus, even though is_valid, is_closed and is_triangular returned true, the mesh was in valid for conversion to a nef polyhedron. From CGAL 4.7. The Polygon mesh processing package has been introduced which contains this which can be used to check for self intersections.

SciLab - Stack size exceeded

So, I have this project for school in which I have to write code in SciLab to solve a puzzle (Tents). The code is getting longer and longer as it gets better and better, but I suddenly got an error stating "stack size exceeded".
Error log:
!--error 17
stack size exceeded!
Use stacksize function to increase it.
Memory used for variables: 28875
Intermediate memory needed: 59987764
Total memory available: 10000000
I tried using this line
stacksize('max')
And this one
stacksize(1e8)
Neither of which works, all that happens is SciLab shutting itself down without any warning at all.
How did I exceed my stacksize? Is there a way to prevent this? How can I continue further?
I figured out myself how to solve this problem. Here's what I did wrong for people with the same problem:
Within a function I used the line
[m,n] = [x,y]
to save the coordinates of an object from a matrix. This was called within a loop using x and y to browse through the matrix.
Apparently this caused the stacksize exceeded error and here's how I wrote it afterwards:
m = x
n = y
I have no idea why this line caused this error, but this is how I've solved it.

libGDX: how to tell if shader log refers to frag or vert shader error

After compiling a ShaderProgram if it doesn't compile I print the log.
However, I can't find a way to tell if the error is in the fragment or vertex shader.
Here I put an error in the frag shader:
0:1(1): error: syntax error, unexpected NEW_IDENTIFIER
This error is in the vert shader:
0:1(1): error: syntax error, unexpected NEW_IDENTIFIER
is there a way to show more detail about where the error is?
Looking at the Libgdx ShaderProgram source I couldn't seem to see one: http://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/graphics/glutils/ShaderProgram.html
Not ideal, but: You can add a blank line at the beginning of one of the two shaders. Then see if the line number for the error changes to determine which one it applies to.