xamarin_find_protocol_wrapper_type crash on Crashlytics dashboard.

[mahebisht]

There is only xamarin_find_protocol_wrapper_type crash is visible on Crashlytics dashboard using .NET MAUI8 for IOS. All the crashes and non fatals coming inside xamarin_find_protocol_wrapper_type with no stack trace.

This is the stack trace for divide by zero error.

I am using Plugin.Firebase for Firebase Crashlytics in IOS for .NET MAUI project. Does .NET MAUI8 support Firebase Crashlytics in IOS?

[AdamEssenmacher]

Plugin.Firebase doesn't use these bindings yet, and would be incompatible with these bindings unless you created a fork of Plugin.Firebase and swapped out the Xamarin.iOS.Firebase.* dependencies.

It's my intent to publish a new major version of Plugin.Firebase using these bindings eventually.

[mahebisht]

Thanks for your reply.

Do you have an estimate when we can get Firebase Crashlytics using Plugin.Firebase

[AdamEssenmacher]

@mahebisht version 3.0.0 has been published

[mahebisht]

Thanks for the update. I am updating the latest version and checking on macbook for IOS.

[mahebisht]

After update to latest version 3.0. I am able to build the solution in Windows. But unable to build the solution in MacBook. I received following error

Xamarin.Shared.Sdk.targets: Error: clang++ exited with code 1: ld: warning: Could not find or use auto-linked library 'swiftCore' ld: warning: Could not find or use auto-linked library 'swiftCompatibility50' ld: warning: Could not find or use auto-linked library 'swiftCoreGraphics' ld: warning: Could not find or use auto-linked library 'swiftCoreImage' ld: warning: Could not find or use auto-linked library 'swiftFileProvider' ld: warning: Could not find or use auto-linked library 'swiftOSLog' ld: warning: Could not find or use auto-linked library 'swiftObjectiveC' ld: warning: Could not find or use auto-linked library 'swiftFoundation' ld: warning: Could not find or use auto-linked library 'swiftCompatibilityDynamicReplacements' ld: warning: Could not find or use auto-linked library 'swiftDarwin' ld: warning: Could not find or use auto-linked library 'swiftCompatibility51' ld: warning: Could not find or use auto-linked library 'swiftQuartzCore' ld: warning: Could not find or use auto-linked library 'swiftUIKit'

[AdamEssenmacher]

https://github.com/TobiasBuchholz/Plugin.Firebase/issues/303#issue-2324663841

[mahebisht]

Hi Adam,

I added following code. I am able to build the solution in MacBook.

<_SwiftPlatform Condition="$(RuntimeIdentifier.StartsWith('iossimulator-'))">iphonesimulator <_SwiftPlatform Condition="$(RuntimeIdentifier.StartsWith('ios-'))">iphoneos <_CustomLinkFlags Include="-L" /> <_CustomLinkFlags Include="/usr/lib/swift" /> <_CustomLinkFlags Include="-L" /> <_CustomLinkFlags Include="$(_SdkDevPath)/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/$(_SwiftPlatform)" /> <_CustomLinkFlags Include="-Wl,-rpath" /> <_CustomLinkFlags Include="-Wl,/usr/lib/swift" />

Thanks for your quick reply Mahendra

[iida-i3]

@mahebisht Were you able to read any understandable logs on the Crashlytics dashboard after build succeeded?

Now I am using version 3.0.0 but I am encountering the exact same problem as the first post in this Issue, so I'm confusing. Sample project that can reproduce is this link .

I confirmed following things.

• I confirmed build log and I could confirm that uploaded and UUID.
• On the Firebase Console, I confirmed that it was uploaded.
• I also checked the UUIDs of the application and dSYM and confirmed that they match.

If anyone knows anything about this, I would be very grateful if you could let me know!

[AdamEssenmacher]

@iida-i3 @mahebisht what you're reporting is expected behavior as far as this plugin is concerned. Pugin.Firebase is a thin wrapper around the native client SDKS, which report native crashes. There's no way for these native SDKs to understand managed .NET stack traces or objects (including exceptions). Those are details internal to Mono.

The native SDKs provide an API to report non-fatal errors manually. This plugin exposes those APIs, and even includes some lightweight stack parsing to help make exceptions reported manually to be readable in the Crashlytics dashboard. So, if you want to be reporting details from managed code in the Crashlytics dashboard, that's your option.

[iida-i3]

@AdamEssenmacher

Accodring to your information, I could send readable logs in the Crashlytics dashboard. I updated sample project.

It was a little difficult but good experience for me. Thank you so much!

[codychaplin]

@AdamEssenmacher Just to clarify, does either AdamE.Firebase.iOS.Crashlytics or Plugin.Firebase.Crashlytics 3.0.0 provide readable fatal error stack traces?

[AdamEssenmacher]

@AdamEssenmacher Just to clarify, does either AdamE.Firebase.iOS.Crashlytics or Plugin.Firebase.Crashlytics 3.0.0 provide readable fatal error stack traces?

Depends on what you mean by "readable". mono_invoke_unhandled_exception_hook is readable and explains very well what's happening. That's what the native crash looks like, and it's being reported accurately.

If you want readable managed stack traces, perhaps you could try combining manual reporting with something from https://github.com/dotnet/maui/discussions/653?sort=top#discussioncomment-3434251

[codychaplin]

Yes I'm talking about logs with specific function names and line numbers like so: The above is the type of stack traces I get with the Xamarin.Firebase.iOS.Crashlytics package, and below is what I get with .NET 8 MAUI (same as the original topic of this issue): I just wanted to clarify whether v3.0.0 added that ability or if it's even possible? Your first comment on this issue suggested that, unless I misinterpreted it. Forgive my ignorance, I'm new to this kind of stuff.

Thank you for the link, I'll most likely utilize AppDomain.CurrentDomain.UnhandledException.

[AdamEssenmacher]

I don't think what you're observing has anything to do with Xamarin.Firebase.iOS.Crashlytics or AdamE.Firebase.iOS.Crashlytics. The AdamE version is functionally identical--it just ships with current native SDKs.

If you were to install the AdamE.Firebase.iOS.Crashlytics package into a Xamarin app (yes, it's compatible!), you could expect to get crash reports just like the ones you see in your first screenshot. Likewise, if you were to install Xamarin.Firebase.iOS.Crashlytics into an iOS.NET 8.0+ app, you could expect to get crash reports like the ones in your second screenshot.

So what happened to the more useful, .NET-friendly native stack traces? My guess is that iOS.NET introduced some changes around AOT and/or the Mono interpreter (MTouch).

See https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter?view=net-maui-8.0

The Mono interpreter overcomes these restrictions while abiding by platform restrictions. It enables you to interpret some parts of your app at runtime, while AOT compiling the rest. However, there are some potential drawbacks to using the interpreter in a production app: ... Native stack traces in crash reports become less useful, because they'll contain generic frames from the interpreter that don't mention the code that's executing. However, managed stack traces won't change.

In any case, neither AdamE.Firebase.iOS.Crashlytics or Plugin.Firebase have anything to do with any of it.

[codychaplin]

Interesting, so it's more of a .NET problem rather than Firebase. Thanks again for info!