[Bug] [iOS] Crash When the First Toolbar Item Has an Icon and a Second Item Gets Added

[abduelhamit]

Steps to Reproduce

1. Build the reproduction project.
2. Tap on a toolbar item.

The relevant code:

public MainPage()
{
    item0 = new ToolbarItem("Item 0", null, ClearAndAddToolbarItems)
    {
        IconImageSource = ImageSource.FromResource("CrashTest.Image_0.png")
    };
    item1 = new ToolbarItem("Item 1", null, ClearAndAddToolbarItems)
    {
        // It doesn't matter if this item has an image or not.
        //IconImageSource = ImageSource.FromResource("CrashTest.Image_1.png")
    };
    ClearAndAddToolbarItems();
    InitializeComponent();
}

private void ClearAndAddToolbarItems()
{
    ToolbarItems.Clear();
    ToolbarItems.Add(item0);
    ToolbarItems.Add(item1);
}

Expected Behavior

No crashs.

Actual Behavior

Unhandled Exception:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'PrimaryToolbarItem'.
  at Foundation.NSObject.get_SuperHandle () [0x00012] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/Foundation/NSObject2.cs:449 
  at UIKit.UIBarButtonItem.set_Image (UIKit.UIImage value) [0x00033] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/UIKit/UIBarButtonItem.g.cs:653 
  at Xamarin.Forms.Platform.iOS.ToolbarItemExtensions+PrimaryToolbarItem.UpdateIconAndStyle () [0x0007e] in <db147fad2aa9412c845ff0ead92dfe20>:0 
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_0 (System.Object state) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1023 
  at Foundation.NSAsyncSynchronizationContextDispatcher.Apply () [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/Foundation/NSAction.cs:178 
--- End of stack trace from previous location where exception was thrown ---

  at (wrapper managed-to-native) UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr)
  at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) [0x00005] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/UIKit/UIApplication.cs:79 
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0002c] in /Library/Frameworks/Xamarin.iOS.framework/Versions/12.8.0.2/src/Xamarin.iOS/UIKit/UIApplication.cs:63 
  at CrashTest.iOS.Application.Main (System.String[] args) [0x00001] in /Users/user/Projects/CrashTest/CrashTest.iOS/Main.cs:17

Basic Information

• Version with issue: 4.0.0.425677
• Last known good version: None
• IDE: Vidual Studio 2019 for Mac
• Platform Target Frameworks:
  • iOS: 12.2
• Nuget Packages: Xamarin.Forms
• Affected Devices: iOS

Reproduction Link

https://drive.google.com/file/d/14VnLQbRIGfDIYxrX6IKK5Bd3cIglrk3I/view?usp=sharing

[jfversluis]

It does seem to have something to do with the fact that at least one of the items has an icon.

This line in the error:

barItem.UpdateIconAndStyle () [0x0007e] in :0

Made me try to comment out the IconImageSource line for item0. When you do that, the code works as expected. After some more digging, I found out it is also fine if you use a ImageSource.FromFile("About.png") instead of the FromResource.

[abduelhamit]

It does seem to have something to do with the fact that at least one of the items has an icon.

The first item must have an icon to trigger the exception. If the first item has not an icon, but the second one has, it works as expected without an exception.

[brcinho]

+1 to fix this. Anyone found a workaround? @jfversluis We use ImageSource.FromFile() for both toolbar items but it seems that it doesn't help. So it is related to how it is named in the title I guess.
Additionally, I can confirm that the issue is of transient nature, it doesn't happen always. If the changes in the toolbar items/icons happen during navigation between pages, it happens usually then. We use AppShell, maybe that additionally increases the chances of reproducing it.

[brcinho]

Additionally, we keep the references of toolbarItems in code behind, and we change the icons dynamically to represent the state of background sync and device connection. We add the try-catch code, but the exception can not be caught, it just crashes the app. So I would kindly ask for a bit more defensive programming, try-catch here and there in the framework, prevention of NPEs with ?. and as operator, here and there. Because we already stumbled upon several issues in xamarin framework where the uncaught exceptions in the framework completely crash our app and we can not do anything to prevent it, other than some time consuming hacks, if we are able to find them.

[brcinho]

Actually, by further investigation we think this crash is related to

CachedImageRenderer.InitImageSourceHandler();

from FFImageLoading library and issue should potentially be opened there.
We commented it out and are now waiting to see if the transient crashes will go away. So far it looks good.

[jfversluis]

Great find @brcinho keep us updated on further developments

[ymebrugts]

I had this crash as well using the shared resources in the Xamarin.Forms project:

var image = ImageSource.FromResource("NameSpaceTo.Resources.EN.png", typeof(CustomPageContainer).GetTypeInfo().Assembly);
LanguageButton.IconImageSource = image;

[samtun]

Can confirm this is related to using FFImageLoading. See the bug in their repo: luberda-molinet/FFImageLoading#1460
Though I am not sure where this bug originates.

[Tommigun1980]

I am not using FFImageLoafing for the icons, but I do have it in the project as a dependency. Are you saying it’s intercepting the calls? A comment in the bug report states “In addition, there are no problems when using IconImageSource for ContentPage or something else.”, isn’t that contradictory?

…

On Monday, July 27, 2020, Fabian Schipp ***@***.***> wrote: Can confirm this is related to using FFImageLoading. See the bug in their repo: luberda-molinet/FFImageLoading#1460 <luberda-molinet/FFImageLoading#1460> Though I am not sure where this bug originates. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6387 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOL6P6FMNZR3MM3K6HTMF2TR5V3XRANCNFSM4HSHWU4Q> .

--

[samtun]

I know, but on my side it crashes 100% when I do the following:

• use CachedImageRenderer.InitImageSourceHandler(); to initialise the FFImageLoading
• use an IconImageSource for a ToolbarItem on a ContentPage

[Tommigun1980]

But then it's not related to using FFImageLoading, rather than FFImageLoading also crashing due to this.

…

On Tue, Jul 28, 2020 at 7:52 AM Fabian Schipp ***@***.***> wrote: I know, but on my side it crashes 100% when I do the following: - use CachedImageRenderer.InitImageSourceHandler(); to initialise the FFImageLoading - use an IconImageSource for a ToolbarItem on a ContentPage — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6387 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOL6P6CSS4MGDG2PT5YSU73R5ZKQZANCNFSM4HSHWU4Q> .

[Tommigun1980]

I have noticed that the crash happens 100% on the first time the menu is rendered on a clean install. Consecutive boots of the app don't show this issue. After it has crashed once, I can not reproduce the crash until I reinstall the app, after which it always happens once the first time it renders the menu.

Please help.

[AlexanderMelchers]

I also ran into this issue yesterday and, to my surprise, found that nobody seems to have reported this issue to the FFImageLoading-team yet, notwithstanding the fact that this clearly seems to be an issue to do with that library. That is, the line causing issues is CachedImageRenderer.InitImageSourceHandler(); in your AppDelegate - removing it will prevent the crash.

Since this line appears to only enable FFImageLoading on image types no directly related to FFImageLoading itself, an easy work-around would be to consistently use FFImageLoading's own controls throughout your app, and disable the aforementioned line in your AppDelegate (this should be possible, assuming you're not loading external images into native controls, such as ToolbarItems, ImageButtons, etc.).

Another work-around that allows you to leave the FFImageLoading's initialization in place is to simply put a delay on insertion of your toolbar item. If inserted a while after the page has been rendered, the app doesn't crash either. As such, it may be enough to simply insert your toolbar item on the page's OnAppearing.

To get things moving with FFImageLoading, I filed a bug report there.

[acuntex]

Also happens with Xamarin.Forms.Nuke.

I guess it happens if you use a custom Image Source Handler and has nothing to do with FFImageLoading specifically.

[acuntex]

This seems to be definitely a crash in Xamarin.Forms
Image = await _item.IconImageSource.GetNativeImageAsync();

Apparently the default implementation by Xamarin.Forms (https://github.com/xamarin/Xamarin.Forms/blob/f35ae07a0a8471d255f7a1ebdd51499e10e0a4cb/Xamarin.Forms.Platform.iOS/Renderers/ImageRenderer.cs) is not really async, it returns without awaiting - therefor there is no time for the control to get disposed. If the implementation, either by FFImageLoading or Xamarin.Forms.Nuke or any other implementation is really async, the toolbar control can be disposed in the meantime and then the crash happens.

@samhouts This seems to be definitely a crash bug in Xamarin.Forms and is not related to either library. I can also imagine other code parts, where there is the same bug.

Before assigning Image of PrimaryToolbarItem or SecondaryToolbarItem, there has to be a check, if the control has been disposed. (Again, this has to be everywhere, where there is Code similar to await _item.IconImageSource.GetNativeImageAsync())

[abduelhamit]

@acuntex My original issue is definitely related to Xamarin.Forms. It's so minimalistic that it can't be anything else.

[acuntex]

@abduelhamit Absolutely.
You can see here:
https://github.com/xamarin/Xamarin.Forms/blob/79cc0f49fe90a59f02aa0490072b449ccdad4a27/Xamarin.Forms.Core/StreamImageSource.cs
that Streams are loaded async (unlike simple FileImageSources that are loaded directly).

Same would happen if you would use a remote image as toolbar item.

@samhouts Any update? This is a crash bug.

[Tommigun1980]

@PureWeen When will 5.0.1 come out? Thank you.

[ramtechjoe]

Any updates on this. It's been open for a long time and is a system crashing bug. I can get this to occur every time by putting the application in background and then rendering the toolbar

Does anyone have good workarounds to keep this from crashing app?

[Tommigun1980]

Any updates on this. It's been open for a long time and is a system crashing bug. I can get this to occur every time by putting the application in background and then rendering the toolbar

Does anyone have good workarounds to keep this from crashing app?

I never did and resorted to removing toolbar images. @jfversluis any chance of fixing this crash in a service release? Thanks!

[ramtechjoe]

I've found that in my situation a workaround was to recreate the ToolbarItem each time the toolbar is reloaded. Previously, I was using ToolbarItem objects in memory and based on certain conditions would add/remove buttons on navigation. This is done via a Behavior attached to the page. I modified so after calling ToolbarItems.Clear() instead of using the existing objects I clone the ToolbarItems. So far this seems to be working for me

_page.ToolbarItems.Clear();

//visibleItemNames lists the Toolbars that will be displayed based on specific conditions
foreach (var name in visibleItemNames)
{
     //_toolbarByName is a dictionary that contains the ToolbarItems 
	_page.ToolbarItems.Add(CloneToolbarItem(_toolbarByName[name]));
}


private ToolbarItem CloneToolbarItem(ToolbarItem item)
{
	var clonedItem = new ToolbarItem()
	{
		Text = item.Text, 
		Command = item.Command, 
		CommandParameter = item.CommandParameter,
		Priority = item.Priority,
		IconImageSource = item.IconImageSource
	};

	return clonedItem;
}

[scriptBoris]

ANY UPDATES???? NEWS??? HELLLOOO???

[jfversluis]

@scriptBoris I understand that you might feel some frustration, I also hope you understand that this will not make us move any faster. We're working as fast as we can. See #14205 for more context.

[jfversluis]

@Tommigun1980 thanks for tagging this! Adding it to our list

[Tommigun1980]

@Tommigun1980 thanks for tagging this! Adding it to our list

Thank you for working so hard on fixing the issues!

Regarding this crash issue, it only happens for me when running my app on a physical device, and only the first time after an install (when the toolbar is rendered).
It never happens for me in the simulator or on consecutive boots of my app even in a physical device. So I have to reinstall the app on a real device every time I want this bug to occur.

So if you can’t reproduce please try those steps.
Thank you again!

[MaximMikhisor]

Possible hack:

Create some marker to mark ImageResource which we are using for toobar item:

public static SomeClass
{
       public static readonly String ToolbarIconMarker= "ToolbarIconMarker";
}

Assign this marker when you create ToolbarItem:

var toolbarItem = new ToolbarItem();

toolbarItem.IconImageSource = _getIconImageSource();

if (toolbarItem.IconImageSource.AutomationId == null)
   toolbarItem.IconImageSource.AutomationId = SomeClass.ToolbarIconMarker;

Somewhere in iOS project

using Foundation;
using System.IO;
using System.Threading;
using System.Threading.Tasks;
using UIKit;
using Xamarin.Forms;
using Xamarin.Forms.Platform.iOS;

[assembly: ExportImageSourceHandler(typeof(StreamImageSource), typeof(CustomStreamImagesourceHandler ))]

namespace Somenamespace
{    
    public class CustomStreamImagesourceHandler : IImageSourceHandler, IAnimationSourceHandler
	{
		StreamImagesourceHandler _handler = new StreamImagesourceHandler();

		[Preserve(Conditional = true)]
		public LsStreamImagesourceHandler()
		{
		}

		public async Task<UIImage> LoadImageAsync(ImageSource imagesource, CancellationToken cancelationToken = default(CancellationToken), float scale = 1f)
		{
			UIImage image;

			if (imagesource.AutomationId == SomeClass.ToolbarIconMarker)
			{
                                // Pay attention, just using simple approach with CancellationToken.None
                                // Implement your solution if you need something different
				Stream stream = ((StreamImageSource)imagesource).Stream(CancellationToken.None).Result;

				image = UIImage.LoadFromData(NSData.FromStream(stream), scale);
			}
			else 
			{
				image = await _handler.LoadImageAsync(imagesource, cancelationToken, scale);
			}

                        // Hack to enable color icons in ToolBar, if you need it
			image = image.ImageWithRenderingMode(UIImageRenderingMode.AlwaysOriginal);

			return image;
		}

		public async Task<FormsCAKeyFrameAnimation> LoadImageAnimationAsync(ImageSource imagesource, CancellationToken cancelationToken = default(CancellationToken), float scale = 1)
		{
			return await _handler.LoadImageAnimationAsync(imagesource, cancelationToken, scale);
		}
	}
}

[jsuarezruiz]

The issue will be fixed by #14749 and we will include it in SR7.

[jfversluis]

If you want you could grab the NuGet as described here and let us know if this fixes this issue? That will greatly speed up the review process.

Besides verifying if this particular issue is fixed also be sure to check other scenarios in the same area to make sure that this fix doesn't accidentally has side-effects 🙂

Thanks!

[skadookkunnan]

Has this issue returned in 5.0.0.2545? It looks like it! @jfversluis @jsuarezruiz
I am getting this issue in the latest Xamarin Forms 5 SDK app.

Unhandled Exception:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Xamarin.Forms.Platform.iOS.ToolbarItemExtensions+PrimaryToolbarItem'.
  at ObjCRuntime.ThrowHelper.ThrowObjectDisposedException (System.Object o) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/ObjCRuntime/ThrowHelper.cs:52 
  at Foundation.NSObject.get_SuperHandle () [0x00012] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/Foundation/NSObject2.cs:580 
  at UIKit.UIBarButtonItem.set_Image (UIKit.UIImage value) [0x0002b] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/UIKit/UIBarButtonItem.g.cs:847 
  at Xamarin.Forms.Platform.iOS.ToolbarItemExtensions+PrimaryToolbarItem.UpdateIconAndStyleAsync () [0x0003e] in D:\a\1\s\Xamarin.Forms.Platform.iOS\Extensions\ToolbarItemExtensions.cs:93 
  at Xamarin.Forms.Platform.iOS.ToolbarItemExtensions+PrimaryToolbarItem.OnPropertyChanged (System.Object sender, System.ComponentModel.PropertyChangedEventArgs e) [0x000e1] in D:\a\1\s\Xamarin.Forms.Platform.iOS\Extensions\ToolbarItemExtensions.cs:77 
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__7_0 (System.Object state) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1021 
  at Foundation.NSAsyncSynchronizationContextDispatcher.Apply () [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/Foundation/NSAction.cs:178 
  at (wrapper managed-to-native) UIKit.UIApplication.xamarin_UIApplicationMain(int,string[],intptr,intptr,intptr&)
  at UIKit.UIApplication.UIApplicationMain (System.Int32 argc, System.String[] argv, System.IntPtr principalClassName, System.IntPtr delegateClassName) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/UIKit/UIApplication.cs:57 
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00013] in /Library/Frameworks/Xamarin.iOS.framework/Versions/16.2.0.5/src/Xamarin.iOS/UIKit/UIApplication.cs:82 
  at Solo.iOS.Application.Main (System.String[] a) [0x00001] in /Users/sagarskadoo/Documents/Developer/OfficeProjects/Ultradata/AzureDevOps/Solo/src/Solo.iOS/Main.cs:17