[BUG] iOS: Crash when GC collects SKMetalView resources #3178
Comments
|
Interesting, I've also experienced an occasional crash using SKMetalView too - might be the same as this one. I notice that the backend context is created twice with the default constructor. So, related in a sense, but probably won't fix this issue: |
|
OK, what I'm seeing is definitely the same problem as described here. It occurs on both iOS and MacCatalyst. As the original stack trace shows, there's a bug disposing/finalizing GRContext with the Metal backend. SKMetalView isn't even required to repro - just creating two CreateAndDisposeMetalContext();
CreateAndDisposeMetalContext();
private static void CreateAndDisposeMetalContext()
{
var device = MTLDevice.SystemDefault!;
using (GRMtlBackendContext backendContext = new()
{
Device = device,
Queue = device.CreateCommandQueue(),
})
{
using GRContext context = GRContext.CreateMetal(backendContext);
}
GC.Collect();
GC.WaitForPendingFinalizers();
}I'll have a look into fixing it, or at least adding the above as a unit test. |
AbandonContext appears to destroy the command buffer, causing the finalizer to crash from a double free. Fixes: mono#3178
|
So, the above code was based on what SKMetalView was doing... The actual crash is coming from here I can't say I'm familiar with Apple APIs or Objective C (and especially not Apple interop). But it looks/feels like a double free situation (i.e. abandonContext freeing the command queue followed by the finalizer). If I manually call retain on the command queue then it at least doesn't crash, but I'm not sure if this is just masks the problem or causes a leak in its place: NSObject o = NSObject.FromObject(commandQueue);
o.DangerousRetain();I've put in a draft pull request with a unit test and a proof of concept for the retain. Hopefully @mattleibow can take a look/take over! |
AbandonContext appears to destroy the command buffer, causing the finalizer to crash from a double free. Fixes: mono#3178
AbandonContext appears to destroy the command buffer, causing the finalizer to crash from a double free. Fixes: mono#3178
AbandonContext appears to destroy the command buffer, causing the finalizer to crash from a double free. Fixes: mono#3178
|
Some bits in Skia showing use of retain for the backend context. Looks like it calls through to CFRetain on the command buffer when creating a test context: https://skia.googlesource.com/skia/+/7755e6ab0bc0/tools/gpu/mtl/MtlTestContext.mm |
Description
SkiaSharp v3.116.1
.Net 9
maui 9.0.0/9.0.100 SDK 9.0.100
maui-ios 9.0.0/9.0.100 SDK 9.0.100
IDE: JetBrains Rider
In our app we have several views, one of which contains an SKMetalView. Every time the GC runs to collect resources, the app crashes with the following stack:
Code
To reproduce the issue SkiaSharpSample.zip:
Expected Behavior
No response
Actual Behavior
No response
Version of SkiaSharp
3.116.0 (Current)
Last Known Good Version of SkiaSharp
2.88.9 (Previous)
IDE / Editor
Other (Please indicate in the description)
Platform / Operating System
iOS
Platform / Operating System Version
iOS 17.5
iOS 18.2
Devices
No response
Relevant Screenshots
No response
Relevant Log Output
Code of Conduct
The text was updated successfully, but these errors were encountered: