Failed to create an SDL2 GL context (Invalid window)

[pcktm]

Type

Crash to desktop

Bug description

AppImage version of the game used to run fine on my system and now it opens a black window and hangs (probably after some system update as I'm on a rolling distro). Tried building from source - builds fine, opens a black window and hangs. I rebuilt flatpak image with never version since the flathub one is outdated and it ran fine for a few weeks but now doesn't even open a window saying:

Unhandled exception. System.InvalidOperationException: Failed to create an SDL2 GL context (Invalid window)
   at osu.Framework.Platform.SDL2.SDL2GraphicsBackend.CreateContext()
   at osu.Framework.Platform.PassthroughGraphicsBackend.Initialise(IWindow window)
   at osu.Framework.Platform.SDL2.SDL2GraphicsBackend.Initialise(IWindow window)
   at osu.Framework.Platform.SDL2DesktopWindow.Create()
   at osu.Framework.Platform.GameHost.Run(Game game)
   at osu.Desktop.Program.Main(String[] args) in /var/lib/buildkite-agent/builds/debian-gnu-linux-vm-1/ppy/osu/osu.Desktop/Program.cs:line 120

$ glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 4096 MB
    Total available memory: 4096 MB
    Currently available dedicated video memory: 3342 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 525.60.11
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6.0 NVIDIA 525.60.11
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 525.60.11
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

$ inxi -SG
System:
  Kernel: 5.19.17-2-MANJARO arch: x86_64 bits: 64
    Desktop: GNOME v: 43.1 Distro: Manjaro Linux
Graphics:
  Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] driver: nvidia v: 525.60.11
  Display: x11 server: X.org v: 1.21.1.4 with: Xwayland v: 22.1.5
    driver: N/A resolution: 1: 1920x1080~60Hz 2: 1080x1920~60Hz
  API: OpenGL v: 4.6.0 NVIDIA 525.60.11 renderer: NVIDIA GeForce GTX 1050
    Ti/PCIe/SSE2

Screenshots or videos

No response

Version

2022.1208.0 but is present in earlier releases too

Logs

database.log
input.log
network.log
performance.log
runtime.log

[peppy]

@Susko3 maybe you'd know about this one? Seems similar to #20481.

[Susko3]

The attached logs don't have the crash you describe, try running the game again and attached the latest logs. How/where did you get the exception stack trace?

[pcktm]

Check out runtime.log, the error message is on the very top, it’s just that the game keeps logging some more after the SDL error. I got the stack trace when running osu! from the flatpak command line but I got a similar trace when debugging osu-framework (maybe we should move the issue there) in Rider.

[Susko3]

@pcktm pull in ppy/osu-framework#5585 and see if you get a more verbose error message.

[pcktm]

Pulled and ran VisualTests from osu-framework since it also exhibits this behavior of displaying a window and hanging but nothing new was logged to console nor logs. Interestingly the InvalidOperationException you added doesn't throw and I even added a debugger breakpoint on it just to be sure - doesn't break.
Attached is the runtime log of visual-tests since it may be less cluttered than osu!
runtime.log

[pcktm]

Even though it's not really helpful, both osu! and visual-test windows look like this:

[pcktm]

The SDLWindowHandle that is compared to the IntPtr.Zero in Create() seems to be correct with value 0x56452a3ebaa0. And well, the window is actually created on the screen...

[Susko3]

This is probably something specific to your system. Not really sure how to go about debugging this.

But give vulkan a try, pull in the latest changes and apply this diff:
(it's not fully implemented, so you'll only see a color-cycling rectangle)

diff --git a/osu.Framework/Platform/GameHost.cs b/osu.Framework/Platform/GameHost.cs
index bc472e5da..67b44c129 100644
--- a/osu.Framework/Platform/GameHost.cs
+++ b/osu.Framework/Platform/GameHost.cs
@@ -40,6 +40,7 @@
 using SixLabors.ImageSharp.PixelFormats;
 using SixLabors.ImageSharp.Processing;
 using osu.Framework.Graphics.Textures;
+using osu.Framework.Graphics.Veldrid;
 using osu.Framework.Graphics.Video;
 using osu.Framework.IO.Serialization;
 using osu.Framework.IO.Stores;
@@ -324,7 +325,7 @@ protected GameHost([NotNull] string gameName, [CanBeNull] HostOptions options =
             };
         }
 
-        protected virtual IRenderer CreateRenderer() => new GLRenderer();
+        protected virtual IRenderer CreateRenderer() => new VeldridRenderer();
 
         /// <summary>
         /// Performs a GC collection and frees all framework caches.
@@ -703,7 +704,7 @@ public void Run(Game game)
 
                 SetupForRun();
 
-                Window = CreateWindow(GraphicsSurfaceType.OpenGL);
+                Window = CreateWindow(GraphicsSurfaceType.Vulkan);
 
                 populateInputHandlers();
 

[pcktm]

Unfortunately, veldrid has some trouble loading some shared library. I've got vulkan-headers and the corresponding drivers installed, yet it throws:

System.DllNotFoundException: Unable to load shared library 'libdl' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibdl: cannot open shared object file: No such file or directory
   at Vulkan.Libdl.dlerror()
   at Vulkan.NativeLibrary.UnixNativeLibrary.LoadLibrary(String libraryName)
   at Vulkan.NativeLibrary..ctor(String libraryName)
   at Vulkan.NativeLibrary.UnixNativeLibrary..ctor(String libraryName)
   at Vulkan.NativeLibrary.Load(String libraryName)
   at Vulkan.VulkanNative.LoadNativeLibrary()
   at Vulkan.VulkanNative..cctor()
   --- End of inner exception stack trace ---
   at Vulkan.VulkanNative.vkEnumerateInstanceLayerProperties(UInt32& pPropertyCount, VkLayerProperties* pProperties)
   at Veldrid.Vk.VulkanUtil.EnumerateInstanceLayers()
   at Veldrid.Vk.VkGraphicsDevice.CreateInstance(Boolean debug, VulkanDeviceOptions options)
   at Veldrid.Vk.VkGraphicsDevice..ctor(GraphicsDeviceOptions options, Nullable`1 scDesc, VulkanDeviceOptions vkOptions)
   at Veldrid.Vk.VkGraphicsDevice..ctor(GraphicsDeviceOptions options, Nullable`1 scDesc)
   at Veldrid.GraphicsDevice.CreateVulkan(GraphicsDeviceOptions options, SwapchainDescription swapchainDescription)

Can't figure out what dependency is missing, libdl seems to be a part of glibc and I do have that...

[frenzibyte]

Looks to be a known issue happening across certain linux distros (mellinoe/nativelibraryloader#19), seems we can fix this locally by using NativeLibrary.SetDllImportResolver.

[pcktm]

Inspired by @frenzibyte comment I linked /usr/lib/libdl.so.2 to /usr/lib/libdl.so and sure enough the window does open and flash some colors, so that must've been it

[pcktm]

To provide more context to this issue I tried tracing it some more in debugger and caught this exception:

System.ArgumentNullException: Value cannot be null. (Parameter 'source')
   at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at osu.Framework.Platform.SDL2DesktopWindow.get_PrimaryDisplay() in /home/pcktm/clones/osu-framework/osu.Framework/Platform/SDL2DesktopWindow_Windowing.cs:line 370

The osu.Framework.Platform.SDL2DesktopWindow.Displays does indeed equal null when osu.Framework\Platform\SDL2DesktopWindow.cs:202 gets executed.

Tried PrimaryDisplay => (Displays ?? getSDLDisplays()).First(); and while LINQ doesn't throw now, the issue wasn't solved...

[pcktm]

Got it! After explicitly setting the runtime in Rider to .NET Core instead of automatic visual-tests finally ran! Looks like for some reason it was selecting Mono?

Anyway, it runs correctly only with the above patch, so there's still something wrong since non-nullable Displays is null at runtime at some point. Is

PrimaryDisplay => (Displays ?? getSDLDisplays()).First();

a good enough fix? If so, I'd submit a PR to osu-framework.

[Susko3]

To provide more context to this issue I tried tracing it some more in debugger and caught this exception:

System.ArgumentNullException: Value cannot be null. (Parameter 'source')
   at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   at osu.Framework.Platform.SDL2DesktopWindow.get_PrimaryDisplay() in /home/pcktm/clones/osu-framework/osu.Framework/Platform/SDL2DesktopWindow_Windowing.cs:line 370

The osu.Framework.Platform.SDL2DesktopWindow.Displays does indeed equal null when osu.Framework\Platform\SDL2DesktopWindow.cs:202 gets executed.

Tried PrimaryDisplay => (Displays ?? getSDLDisplays()).First(); and while LINQ doesn't throw now, the issue wasn't solved...

Could you post the full stack trace?

Is

PrimaryDisplay => (Displays ?? getSDLDisplays()).First();

a good enough fix? If so, I'd submit a PR to osu-framework.

This is not a proper solution. Displays being null here is the underlying issue.

[pcktm]

It appears that there may be a race condition causing the deadlock?

Debugging the code step-by-step seems to allow the frames to be drawn correctly, but when running freely, the issue occurs after a few (amount isn't constant) executions of the osu.Framework.Platform.GameHost.DrawFrame function. Rarely I get lucky and the game does start up successfully so it may be something during init, however it is unclear at this time what is root cause of this behavior.

The previously mentioned issue with Displays being null is not relevant to this issue, my bad.

[pcktm]

I was able to successfully launch the game consistently by debugging the first few frames step-by-step and then muting all breakpoints. The game launches without hanging when visual tests are run after this process.

[pcktm]

After setting the ExecutionMode to SingleThread, the osu! game was able to launch successfully. However, there still appears to be an issue with the multithreaded mode on my system but I do not have the expertise to troubleshoot this issue further. I'd be happy to provide the development team any additional info. Thank you!