glDrawElements producing INVALID_OPERATION or segfault

Newbie & Debugging Questions
#1

I have a glDrawElements call in a large library of mine that produces INVALID_OPERATION on macOS and a segfault in Ubuntu 16.04. Additionally, if I remove some of the glGetError checks, it no longer produces either result in either OS. It works partially: I should be seeing lots of little squares flashing colors and one big white square, all rotating around the Y axis, but I only get a big square flashing colors. I find this to be very strange.

Here’s the library: https://github.com/TechShroom/EmergencyLanding/tree/feature/sound (make sure you have the branch linked)
Use ./gradlew run to run it. If you’re not on OSX you need to remove the -XstartOnFirstThread from the argument list at the bottom.

The glDrawElements call that is failing: https://github.com/TechShroom/EmergencyLanding/blob/feature/sound/src/main/java/com/techshroom/emergencylanding/library/lwjgl/render/VBAO.java#L337
Notice how it is followed by something that checks the debug level. If you remove the -Del.debug.level=5 argument from the arguments list, the problem will stop happening. It occurs with it present. If anyone can even give me a lead on where it might be, I’d be extremely grateful.

#2

You’re most likely somehow causing the driver to read out-of-bounds data. Either the vertex attribute pointers or the index data pointers are telling the driver to read an invalid memory address, or the indices your index data holds are causing the driver to read vertex data data out of bounds.

#3

As it happens, I’m about to debug a similar issue. In my case, the code currently runs fine on MacOS, but shows a black screen or garbage output on one Windows machine, and segfaults on another on the first call of glDrawElementsBaseVertex().

I didn’t touch render code and geometry data, so it’s unlikely that I’m reading out-of-bounds. But I found that some of my transforms are broken (contain #NaN) on the Windows PC which segfaults, in code I did modify recently. This is in the modelViewProj matrix I’m writing to shader uniforms.

So, my advise: check your transformation matrices, too. :o :point:

#4

FYI in my case it appeared to be an issue with shared GL contexts.

I’ve tried to render scenes, using shared GL resources, to two different windows with LWJGL3. I had to learn / be reminded that, according to the GL specs, this isn’t supported for VAO and FBO. The MacOS driver doesn’t seem to care, but on Windows bad things happened.