Access Violation on glDrawElements

[McManning]

Got hit with the following:

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FFD8BE24013
Module  : C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_e0a5a1b06de180e3\nvoglv64.dll

I can reproduce this with:

1. Start a new default cube scene and turn on the render engine (just the builtin fallback shader is fine)
2. Change the default light to a sun
3. Delete the default cube
4. Add another mesh object
5. Use the aim widget on the light to change the orientation

Step 5 causes the exception while calling glDrawElements on the new mesh. Changing light orientation through the UI instead of the aim widget in the viewport doesn't crash. Neither does jumping back to the default viewport render mode, moving the aim widget, and then jumping back to my renderer.

Memory leak? Or memory freed somewhere that I'm still holding onto via the VAO? I assumed I'm safely managing it but maybe I'm missing something there.

[McManning]

It seems like after the actions are taken, the call to glDrawElements changes. I'm not an expert on Blender internals, so I'm having difficulty parsing the stack but this is what's expected on each call:

And this is what's called when the exception occurs:

The values in bgl_var# match the arguments passed into glDrawElements (GL enum flags, number of indices, etc) when it doesn't work - and are all zeroes when it works as expected.

[McManning]

Made some tweaks to how the VAO is setup / fixing some issues with it skipping certain attributes. Still have the same issue on 2.82 but my debug build of 2.83.1 seems to be working fine so far. Tempted to call this a won't fix, but I wanna stress test it some more first.

[McManning]

While not entirely resolved on the main project, this was fixed in micro.py in 0387993. Will basically need to do a pretty large refactor to ensure that all GL calls are done from the render thread moving forward. Otherwise there will be compatibility issues with 2.91.