I'm confused why the following code is having a SystemAccessViolation occur when I uncomment out the line that calls the action.
GL.Enable(EnableCap.DebugOutput);
GL.Enable(EnableCap.DebugOutputSynchronous);
Action action = () => { Console.WriteLine("Hello"); };
DebugProc debugProc = (source, type, id, severity, length, message, userParam) =>
{
string msg = Marshal.PtrToStringAnsi(message, length);
Console.WriteLine("Debug message: " + msg);
// Uncommenting this causes a SystemAccessViolation.
//action.Invoke();
};
GL.DebugMessageCallback(debugProc, IntPtr.Zero);
When I run it in a non-debugging mode, I get:
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at OpenTK.Graphics.OpenGL4.GL.BufferData[T2](BufferTarget target, Int32 size, T2[] data, BufferUsageHint usage)
When I run it with debugging, I get:
Unexpected exception: Object reference not set to an instance of an object.
Stack trace:
at System.StubHelpers.StubHelpers.CheckCollectedDelegateMDA(IntPtr pEntryThunk)
at OpenTK.Graphics.OpenGL4.GL.BufferData[T2](BufferTarget target, Int32 size, T2[] data, BufferUsageHint usage)
I am also unsure of whether my problem is something that I should report to OpenTK, or if I'm doing something wrong in C# (using C# 8, .NET Framework 4.8).
The above code works just fine as long as the action is invoked inside the lambda is commented out.
For anyone not familiar with OpenGL, GL.DebugMessageCallback() will be doing some native stuff most likely. Because of this, I do not know if it means C# loses track of the action and tries doing something it shouldn't, or if there's something that OpenGL is doing that is not playing nice with the code I've written. Is it possible that the GC has cleaned up the action and it's trying to invoke it? I am guessing at this point however.
I cannot put a breakpoint inside of it when action() is uncommented, the breakpoint is not triggered. I can make the breakpoint work when action() is fully commented out however. The ordering of the invoking does not matter whether it's at the top of the lambda or the bottom.
