OpenGL access violation on integrated graphics

Question

Apologies for the somewhat vague title, but I'm getting a pretty vague bug.

I have a C++ project written in MSVC that uses GLEW and GLFW3 so that I can make use of OpenGL 4.3 compute shaders. The project runs brilliantly on my desktop with an AMD graphics card, however on my laptop with an i5-4300u I get a confusing little exception:

Exception thrown at 0x00007FFE99113E4A (ig75icd64.dll) in Examples.exe: 0xC0000005: Access violation reading location 0x0000000000000028.

This happens whenever I call glDispatchCompute(x,y,z) followed by glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT) .

GLEW and GLFW definitely both get initialised as I call this code and don't get any ouput:

int glfw_err = glfwInit();
if (glfw_err == GLFW_FALSE)
{
    printf("ERROR INITIALIZING GLFW\n");
    glfwTerminate();
    return;
}

and:

GLenum glew_err = glewInit();
if (glew_err != GLEW_OK) {
    printf("ERROR INITIALIZING GLEW: %s\n", glewGetErrorString(glew_err));
    return;
}

ig75icd64.dll mentioned in the exception is an Intel graphics driver library, and I did find some mention of broken drivers online, but reinstalling my drivers doesn't seem to have fixed it.

I'm sure the project did run on my laptop at some point, suggesting that's it's something I've done to break it, but I can't confirm this. The Intel Ark website also says the integrated graphics should support OpenGL 4.3

Any help would be much appreciated! Thank you!

Answer 1

Initially I deleted this post as I struggled to recreate the steps to produce the exception.

Hopefully this answer might help people facing similarly hard to track down bugs.

I was getting an access violation, because I was reading outside of SSBOs that I'd specified. Visual Studio was horrible at hinting at where this exception was actually coming from which made it very hard to debug.

I had actually been using the block index and binding index values incorrectly. Thinking there was no such thing as a binding index, I made calls to glBindBufferBase using the block index of the SSBO in the shader program which was obviously a mistake.

My theory for why this wasn't occurring on my AMD GPU is that my block indexes and binding indexes just happened to conveniently line up.

Because I found it hard to find resources here is the process I go through to write data to an indexed SSBO:

GLuint block_index = glGetProgramResourceIndex(shader_program, GL_SHADER_STORAGE_BLOCK, "name_of_ssbo");
GLuint ssbo;
glGenBuffers(1, &ssbo);
GLuint binding_index = <number lower than MAX_SHADER_STORAGE_BUFFER_BINDINGS>;
glShaderStorageBlockBinding(shader_program,block_index,binding_index);
glBindBuffer(GL_SHADER_STORAGE_BUFFER, ssbo);
glBufferData(GL_SHADER_STORAGE_BUFFER, sizeof(<data>), &<data>[0], GL_STATIC_DRAW);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, binding_index, ssbo);

Followed by glDispatchCompute(x,y,z);