Fix SIGSEGV on Android startup from null Vulkan surface handle - #221
Merged
Conversation
Three-layer defense against null pointer dereference (SIGSEGV at pc=0x0) when the Android native surface is not yet ready during Vulkan initialization: 1. VeldridDevice.cs: Poll-wait up to 5s for Android surface handle to become non-zero before creating Vulkan swapchain 2. VkSurfaceUtil.cs: Guard against null ANativeWindow from ANativeWindow_fromSurface 3. DrawThread.cs: Wrap initial BeginFrame/FinishFrame in try-catch Co-authored-by: winnerspiros <1675249+winnerspiros@users.noreply.github.com>
Copilot created this pull request from a session on behalf of
winnerspiros
April 20, 2026 18:10
View session
There was a problem hiding this comment.
Pull request overview
Updates the osu-framework submodule to incorporate upstream fixes that prevent an Android startup SIGSEGV caused by a null/zero Vulkan surface handle during early window/surface initialization.
Changes:
- Bump
submodules/osu-frameworkto a commit containing a three-layer mitigation (poll/wait in swapchain creation, native surface null-guard with a managed exception, and draw-thread BeginFrame deferral).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Android native
SurfaceViewisn't guaranteed to exist when the SDL thread starts the game loop.AndroidGameWindow.SurfaceHandlereturnsIntPtr.Zero, which propagates throughVeldridDevice→VkSurfaceUtil.createAndroidSurface→ANativeWindow_fromSurface(null)→ SIGSEGV atpc=0x0inside the Vulkan driver.Changes
Three-layer defense, all in the osu-framework submodule:
VeldridDevice.cs— Poll-wait up to 5s for the Android surface handle to become non-zero before creating the swapchain. This is the primary fix; the surface is typically ready within a few hundred ms.VkSurfaceUtil.cs— Null-checkANativeWindowafterANativeWindow_fromSurfaceand throw a descriptiveVeldridExceptioninstead of letting the driver SIGSEGV.DrawThread.cs— Wrap initialBeginFrame/FinishFramein try-catch so the draw loop can defer gracefully if the surface still isn't ready.