Access Violation in SwapBuffers()

[Johan-Sandqvist]

I get "Access Violation" In the last line of code below when calling glControl.SwapBuffers() from my program.
No exceptions thrown.

    public void SwapBuffers()
    {
        if (IsDesignMode)
            return;

        EnsureCreated();
        // FIXME: See [MemberNotNull] comment on EnsureCreated().
        if (_nativeWindow == null)
            throw new Exception("EnsureCreated() failed to create _nativeWindow. This is a bug.");
        _nativeWindow.Context.SwapBuffers();
    }

Looking at the comments of the code there seems to be a few known bugs.. Is this component still under development ?

Cheers /Johan

[NogginBops]

An access violation is often an indication that you have bugs in your OpenGL code, usually related to not uploading enough data to buffers (ie paint the wrong size) or drawing more vertices than there are in a buffer. It's unlikely that this is a bug in GLControl.

A good way to debug this is to setup debug callbacks as OpenGL will rarely crash where the actual error is. Here is a guide on how to enable it:
https://opentk.net/learn/appendix_opengl/debug_callback.html?tabs=debug-context-4%2Cdelegate-gl%2Cenable-gl

[Johan-Sandqvist]

Big thanks for the response. I have trippelchecked all models for correct number of vertices / Indexes and that they all are of correct type. Everything renders fine separately. The crash occurs after I start using EBO's (indexed objects). The EBO objects render fine separately but loading objects AFTER causes a crash.

Since I am using GlControl that encapsulates the window, I'm not sure how to setup a debugger ?? The text suggests linking it by
GameWindow window = new GameWindow(
With at flag "GraphicsContextFlags.Debug);"

Any suggestions are much appreciated.. /Johan

[NogginBops]

Errors related to EBOs are common due to a common misunderstanding of how they are supposed to be setup (due to pretty bad API design).
So the thing with EBOs is that the binding target BufferTarget.ElementArrayBuffer is not global state like BufferTarget.ArrayBuffer is. Instead BufferTarget.ElementArrayBuffer changes the state of the current VAO you have bound, in contrast to BufferTarget.ArrayBuffer which just changes which buffer is the current array buffer. So if you for example bind a new VAO the buffer at BufferTarget.ElementArrayBuffer is going to be different, and crucially if you don't have a VAO bound accessing BufferTarget.ElementArrayBuffer is undefined behavior. So there are many gotchas with EBOs, the easiest thing to check is just that you are binding your VAO before you bind your EBO, and that you are never unbinding the EBO as it would remove the EBO from the VAO.

As for setting up the debug callback with GLControl there is GLControlSettings.Flags that you can use to set the Debug flag, there is also a property on the control that you can set from the WinForms editor if you'd prefer that. The rest of the code in the tutorial you can run in OnLoad.

[Johan-Sandqvist]

Thank you so much for excellent answer. I found the bug causing the Access Violation and it was in my code during the binding of the VBO where I put VAO instead by mistake, so the glControl was not to blame. I guess I was slightly spooked when I saw the comment "this is a bug" in the source. Spent two days debugging but now life is good again.
I really like the control and hope that development continues. Since this is not an issue should/can I remove it ?
Thanks again for your great help.
/Johan

[NogginBops]

The message "this is a bug" is only a bug if it ever gets printed out. It's to tell users, if you ever see this message in your log there is a bug in our code.