Strange OpenGL context destruction right before glDrawArrays/glDrawElements


I’m having quite a bit of trouble getting OpenGL to work lately, and it’s driving me crazy. For some reason, when I call glDrawArrays or glDrawElements, my GLFW window gets closed, the OpenGL context is destroyed and a segmentation fault occurs (because the graphics driver tries to draw to a non-existent context).

I haven’t encountered this issue before, and it’s very strange to me that such a thing can happen.
This is my call to glDrawArrays:

This issue only starts occuring when I put my vertex data seq into a separate object. When it’s stored as a local variable, the segmentation fault doesn’t occur, and everything renders properly. It occurs somewhere in the driver, but I can’t check where and why, because Nvidia’s drivers are closed-source. I can only tell it doesn’t occur on Mesa drivers, they simply don’t render anything.

Here’s a screenshot of what GL calls occur, as recorded by apitrace:

As far as I can tell, nothing’s calling glXDestroyWindow and glXDestroyContext right at the end. I don’t call them from my code, at least, as you can see in the linked source code. The very same thing occurs when glDrawElements is called. If I comment out the call, those glXDestroys don’t occur at all.

Has anyone encountered a similar issue? I’ve been debugging this for nearly two days and I just can’t think of what could be causing this. I’m using GLAD as my OpenGL wrapper, and GLFW for windowing.

How do you know that the context has been destroyed?

I’m fairly certain it has – I mean, it’s clear glXDestroyContext gets called.

According to the apitrace output, you’re calling glVertexAttribPointer with a null data pointer and no array buffer bound (then binding an array buffer afterwards, which doesn’t do much good). That’s likely to cause a segfault when you call glDrawArrays.

The fact that the glXDestroyWindow and glXDestroyContext calls appear before the glDrawArrays call may just be an artefact of how apitrace works. I’d be inclined to assume that they’re occurring in response to a segfault in glDrawArrays rather than prior to it.

1 Like

Oh gosh, I thought the VAO was the thing that stores vertex attributes! Thank you a lot for your answer.

A VAO is a container type. It stores a reference to the buffer object (VBO) holding the attribute data for each attribute array. A call to glVertexAttribPointer stores its arguments in the VAO, as well as the handle of the buffer which is bound to GL_ARRAY_BUFFER at that point.

In the case of objects, OpenGL historically preferred to use the object currently bound to some target rather than taking object names (handles) as function parameters. Although this has started to change with the new vertex specification commands in 4.3 (glBindVertexBuffer etc) and the incorporation of direct state access (DSA) in 4.5.

1 Like