(bug) Stack Overflow Exception occurs in GameWindow after about 387,000 loops when running on x86

[sebagamesdev]

Description

Stack Overflow Exception occurs in GameWindow after about 387,000 loops when running on x86.
It seems that this issue does not occur on x64.

Repro steps

1. Create a .NET 6.0 Console Application
2. Add the latest stable OpenTK (4.7.7)
3. Write minimal GameWindow code
4. Compile and run it on the x86 platform

Minimal code:

using OpenTK.Windowing.Desktop;

var settings = new GameWindowSettings();

var nativeSetting = new NativeWindowSettings {
    Vsync = OpenTK.Windowing.Common.VSyncMode.Off
};

var window = new GameWindow(settings, nativeSetting);

window.Run();

Expected & Actual behavior

The program will crash with a Stack Overflow Exception after about 387,000 loops.
(This could take about 10~100 seconds, depending on the speed of your system.)

Related information

The exact same issue occurred every time I tried it, on at least 2 computers (desktop and laptop).

• Operating system: Windows 10 Home
• Version of OpenTK via NuGet
• Runtime (.NET 6.0)

[NogginBops]

Yeah I think we've seen this error pop up before when running OpenTK in 32-bit mode. I don't remember the exact issue, but it's likely some issue related to interop. I'll try look up the issues this has been mentioned in and link them here.

[NogginBops]

It seems like I'm unable to reproduce this bug. I'm running the repro you provided as a 32-bit application and it seems to be running fine. If you have any more information that could help to diagnose the issue that would be great.
Are you running a 32-bit version of windows? or are you just compiling the program as 32-bit?
Are you able to see the stack trace when the exception occurs? if so, could you share it?

[Avibah]

I was able to reproduce this bug on my machine and it happens relatively quickly when running. I am on 64-bit Windows 10 compiling as 32-bit. I seem to get different stack traces depending on whether or not I have a controller plugged in but the thrown error is the same. Attached are both stack traces I was able to obtain using identical source code as the provided picture, although the error seems to still happen if VSync is enabled.

(Without controller)

(With controller)

Update:
I tried Visual Studio's Decompile Source Code option after the error was thrown, resulting in these lines being given as the exact location of their respective errors:

(Without controller)

(With controller)

Something else to note is I tried running Console.WriteLine(GL.GetError()); in the OnRenderFrame event of NativeWindow to try seeing if it would yield anything useful, resulting in a completely different location for the same error, this time being entirely separate from OpenTK:

[NogginBops]

@Avibah What version of OpenTK.redist.glfw are you using? Can you print the GLFW version at runtime with Console.WriteLine(GLFW.GetVersionString())?

[Avibah]

@NogginBops Doing so printed this: 3.3.8 Win32 WGL EGL OSMesa VisualC DLL

[NogginBops]

This issue is still at large and no further info has been collected. It's likely some native interop where the ABI doesn't match 100% while running the application as a 32-bit application.

I can't reproduce the issue so not sure what to do here. Postponing this to 4.8.1.

[NogginBops]

As nothing has happened with this issue I'm going to more this for 4.8.2.

[MV10]

Maybe #1494 is where this was seen before?

I couldn't reproduce this, either. I used the very simple LocalTest project in the repository, at various times running a release build, a stand-alone debug build, and debug in VS2022 (v17.7.4). I added a frame counter so I could keep track, and let it loop for very long periods of time all morning while I worked on other things. Some tests ran for more than ten million frames.

Same GLFW version string mentioned above, and .NET 6.0.317, Win11 22H2, NVIDIA driver 531.79.

[NogginBops]

I'm likely going to more this issue to OpenTK 4.8.3 unless a repro can be made.
Does this still happen for you in 4.8.1 @sebagamesdev and @Avibah ?

[NogginBops]

Moving this to 4.8.3.