[BUG] SIGABRT: Object reference not set to an instance of an object

[arashcoder]

Description

Hi! I'm using Microcharts library, which uses SkiaSharp under the hood. Occasionally on iOS, I get null reference exception. Here's all the crash log I get:

Code

SKCGSurfaceFactory.CreateSurface (CoreGraphics.CGRect contentsBounds, System.nfloat scale, SkiaSharp.SKImageInfo& info)
SKCanvasView.Draw (CoreGraphics.CGRect rect)
(wrapper managed-to-native) 
UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr)
UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate)
UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName)
Application.Main (System.String[] args)

Expected Behavior

It shouldn't crash.

Actual Behavior

It crashes occasionally.

Basic Information

• Version with issue: 1.68.0
• Last known good version:
• IDE: Visual Studio for Mac
• Platform Target Frameworks:
  • iOS: 13.4
• Target Devices: iPhone 8 Plus, iPhone XR, iPad (5th gen, Wi-Fi)

Any ideas why this occurs?
Thanks in advance.

[mattleibow]

Does it still crash if you update to the latest v1.68.3?

[arashcoder]

Thanks for the suggestion. I will try that, but since I can't reproduce that crash I can't be sure.

[arashcoder]

@mattleibow I updated to v1.68.3 and I still get that crash occasionally.
Any ideas?
Thanks.

[mattleibow]

Could you paste the full stack trace? Very weird.

[arashcoder]

That's the whole stack trace that I get in AppCenter.

[mattleibow]

This is very weird because there is not any way to get nulls...
https://github.com/mono/SkiaSharp/blob/v1.68.3/source/SkiaSharp.Views/SkiaSharp.Views.Apple/SKCGSurfaceFactory.cs#L26-L59

The only possible way to get a null is with this line:

bitmapData = NSMutableData.FromLength(info.BytesSize);

That should not return null, so this whole thing looks off.

Do you have any other info that may possibly be related? Is this a big graph, small graph, animated? What was happening before/during updates. Maybe you are accessing something from a background thread and there is a hidden exception.

Are you able to share the actual text message form the exception?

[arashcoder]

Thanks for the explanations. Indeed it's strange.
This is the whole log that I get from this exception. I don't think I'm doing anything special with the graphs, and it's working almost all the time. The problem is that I can't reproduce this, so I don't have a full stack trace.
Also could this line cause the crash?
Info = info = CreateInfo((int)contentsBounds.Width, (int)contentsBounds.Height);

[mattleibow]

That is working with structs, which cannot be null. How rare is this exception? Maybe iOS just decides that it will return null when it feels like it.

[yungkakin]

I am also encountering this issue. Not easy to reproduce but it indeed happens on iOS. (Never happen on Android in my case)
The SkiaSharp version I am using is 2.80.2.

[arashcoder]

So could someone please have a look at this?

[yungkakin]

It seems no one is going to handle this issue. Is SkiaSharp really stable on iOS?

[richirisu]

Hello, I am new to this conversation. I can confirm that this issue does indeed occur from time to time. It is more likely to occur in situations of low memory, e.g. when using SkiaSharp to render full-screen. Indeed, NSMutableData.FromLength is not supposed to return null by default, but it is possible when there is not enough (continuous) memory available to allocate in the first place. Then null will be returned.

Of course, I am unaware about how to proceed best in case there is not enough memory to allocate for the drawing surface. I mean, continuing with a blank surface is not a proper solution either.

By the way, I get the same crash log as arashcoder has in his first post.

[mattleibow]

I'll have another look as this seems like it should not happen. We had a memory block that we just freed, so there should be some memory.
Also, this only runs when the view bounds changes as we reuse the data object between paints.

Is there some sort of view changes happening when it crashes?

What I could do is check for null and throw a better exception and see if that appears in the stacktrace so we know for sure?

[richirisu]

No pressure, and thanks for looking further into it.

In my case the Xamarin.iOS application opens a Xamarin.Forms Page whose entire content is a single SKCanvasView. The crash occurs at creation time, more precisely, when the page becomes visible for the first time. It does not even get to any custom drawing code. As such, I suppose no bitmap data has been allocated yet. With the currently biggest iPad resolution available a chunk of 22 MB is necessary that must fit in one continuous space in memory. And depending on current memory usage this is sometimes a problem.

As mentioned before, it does not happen all the time and it is more likely to occur on a device that has many applications installed / opened. The aforementioned page can be closed and opened over and over again, thus, allocating a new SKCanvasView each time. In general, this is not a problem. Further, the few crash reports I got all have in common that they occurred roughly a week after the application was launched. Memory leaks and memory defragmentation might increase the chances, as it seems.

In respect to the stack trace, I doubt throwing another exception in return is going to help much. Of course, it would slightly be more expressive than a null reference exception. However, if an exception is not handled in the Draw method of an UIView, the application will crash consequently.

https://github.com/mono/SkiaSharp/blob/v1.68.3/source/SkiaSharp.Views/SkiaSharp.Views.AppleiOS/SKCanvasView.cs#L81-L106

As far as I understand, OnPaintSurface is not called if the surface size is empty. So maybe it is a viable workaround to simply render a blank canvas in case of an exception, or as an alternative, to render the message of the exception directly to the canvas (not a fan of the latter though but I have seen many design tools doing exactly that). I have to admit, it’s not very elegant though. At least the result would be that the application won’t crash right away, just the canvas view being blank.

Still, I think, there should be a means to let the implementer know that the bitmap data could not be allocated properly.

Performance-wise, I am not sure how the costs are for having a try-catch-block in the draw method.