iOS MAUI app immediately crashes in `Debug` only

exquirentibus commented 2 weeks ago

Package

Sentry

.NET Flavor

.NET

.NET Version

8.0.8

OS

iOS

SDK Version

4.10.2

Self-Hosted Sentry Version

No response

Steps to Reproduce

Deploy to my iPhone in Release. Run it. The app crashes. No events are reported. If I deploy a Release version, it runs as expected. I get events for a divide by zero exception I'm using to test upon a button press.

Expected Result

not to crash or at least to create an issue/event

Actual Result

crashes without any indication of why

jamescrosswell commented 2 weeks ago

Deploy to my iPhone in Release. Run it. The app crashes. No events are reported. If I deploy a Release version, it runs as expected.

I'm not sure I understand. You you deploy "in Release" and it crashes. Then you deploy "a Release version" and it doesn't. What do you mean here by "in Release"?

exquirentibus commented 2 weeks ago

Deploy to my iPhone in Release. Run it. The app crashes. No events are reported. If I deploy a Release version, it runs as expected.

I'm not sure I understand. You you deploy "in Release" and it crashes. Then you deploy "a Release version" and it doesn't. What do you mean here by "in Release"?

My apologies!! Just getting over the expected effects of new Covid vaccine.

I meant to say When I Deploy to my iPhone in 'Debug' mode it crashes. When I deploy in 'Release' it runs as expected.

bitsandfoxes commented 2 weeks ago

I've run into one of those once or twice before and they were notoriously hard to reproduce. The last one was related to #3540 Would you be able to provide us with some logs from the crash or maybe even a repro?

exquirentibus commented 2 weeks ago

I've run into one of those once or twice before and they were notoriously hard to reproduce. The last one was related to #3540 Would you be able to provide us with some logs from the crash or maybe even a repro?

The app is a very large commercial app that's in active use by 120 users so posting the code isn't possible. It's only been run with Sentry on my phone so I'd be glad to grab logs that might be shown by Xcode. I apologize and am not that familiar with Apple logs as they are gibberish to me coming from the Window world.

If there's a tech note that described what I needed to provide as far as Apple logs I'd be glad to do that.

jamescrosswell commented 2 weeks ago

I meant to say When I Deploy to my iPhone in 'Debug' mode it crashes. When I deploy in 'Release' it runs as expected.

Ah, I see. That's somewhat good news - if it happens in Debug then there are some things we can try to get more information.

Does it crash if you run the app from an IDE (e.g. Visual Studio or Rider)? If so, can you try setting SentryOptions.Debug = true when initialising Sentry? Once you've enabled debug mode, you should see some output in either the IDE Console (on Rider) or Trace (on Visual Studio) windows, when you try to start the application... so even though no errors get sent to Sentry.io, you might have some clues in the debug output on your IDE indicating what went wrong.

Typically the only reason the SentrySDK itself should crash on startup is if it has been misconfigured (e.g. if no DSN has been supplied during initialisation/configuration)...

exquirentibus commented 2 weeks ago

Does it crash if you run the app from an IDE (e.g. Visual Studio or Rider)? If so, can you try setting SentryOptions.Debug = true when initialising Sentry? Once you've enabled debug mode, you should see some output in either the IDE Console (on Rider) or Trace (on Visual Studio) windows, when you try to start the application... so even though no errors get sent to Sentry.io, you might have some clues in the debug output on your IDE indicating what went wrong.

It does Not crash in Release. But with Zero changes at all to the code if I try to Debug from VS2022 using my iPhone instead of deploying it to my iPhone and testing .. it shows the initial splash screen and then dies in Program.cs

static void Main(string[] args) {

UIApplication.Main(args, null, typeof(AppDelegate));

with this exception:

System.TypeLoadException Message=Could not set up parent class, due to: Invalid generic instantiation assembly:/private/var/containers/Bundle/Application/5AB4B561-62E4-4093-B83F-F536B364AC2E/MauiDiag.app/Microsoft.Maui.dll type:ViewHandler`2 member:(null)

jamescrosswell commented 2 weeks ago

It's hard to say what might be causing that without seeing the code. Are you able to share a minimum reproduction of the issue (e.g. as a github repo)?

exquirentibus commented 2 weeks ago

It's hard to say what might be causing that without seeing the code. Are you able to share a minimum reproduction of the issue (e.g. as a github repo)?

James - it's a large multi-screen app with maybe 30 libraries. I'm afraid I don't have time to try to distill a minimal bit of code to reproduce the problem .. at least Quickly.

I'll see if I can strip things out bit by bit on a test build over time but isolating the offending code is going to be tricky!!

I might put in break points to see just how far it gets and maybe that will tell me something but Apple doesn't like delays when the app is starting up so that will also take some time.

As the offending code (Platforms/IOS/Program.cs) specifically mentions AppDelegate, my guess it has something to do with the Platforms/IOS/AppDelegate.cs which is here:

using Foundation;
using UIKit;

namespace MauiDiag {
    [Register("AppDelegate")]
    public class AppDelegate : MauiUIApplicationDelegate {
        protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp(); // call during app startup

        [Export("application:didRegisterForRemoteNotificationsWithDeviceToken:")]
        public void RegisteredForRemoteNotifications(UIApplication application, NSData deviceToken)
            => global::Shiny.Hosting.Host.Lifecycle.OnRegisteredForRemoteNotifications(deviceToken);

        [Export("application:didFailToRegisterForRemoteNotificationsWithError:")]
        public void FailedToRegisterForRemoteNotifications(UIApplication application, NSError error)
            => global::Shiny.Hosting.Host.Lifecycle.OnFailedToRegisterForRemoteNotifications(error);

        [Export("application:didReceiveRemoteNotification:fetchCompletionHandler:")]
        public void DidReceiveRemoteNotification(UIApplication application, NSDictionary userInfo, Action<UIBackgroundFetchResult> completionHandler)
            => global::Shiny.Hosting.Host.Lifecycle.OnDidReceiveRemoteNotification(userInfo, completionHandler);

    }
}

I used Shiny.net for Push notifications which work fine in either Release or Debug without Sentry?

Sentry is rather cool in that it's storing exceptions when there's no Internet. Nuclear techs use the app deep in hospitals with .. no .. connectivity at times so this should be invaluable to reveal some exceptions that TestFlight won't record (with no Internet) and my own Serilog custom logging sink that writes to a remove SQL Server using gRPC .. also won't record exceptions with no Internet.

I've been able to replace Serilog with Sentry so that I have kept by existing exception handlers without change (but haven't setup all the declares to skip including Serilog's libraries yet.) A very nice product I'm looking forward to learning how to use properly.

I'm making it so that one single project settings will either include or exclude Sentry in case I need to abort my testing with Sentry.

<PropertyGroup Condition="True">
  <!-- Set the SENTRY define constant -->
  <DefineConstants>$(DefineConstants);SENTRY</DefineConstants>

  <!-- Directly set the SentryEnabled property -->
  <SentryEnabled>true</SentryEnabled>
</PropertyGroup>

bitsandfoxes commented 2 weeks ago

Since you're using Visual Studio 2022 there have to be some logs somewhere and a stacktrace for that crash. In Debug it should hit the error in some sort of breakpoint as well, right? Can you share those with us? It's fine to just dump the whole logfile on us. (or send it to stefan@sentry.io if you have some stuff in there that you're not comfortable sharing here)

exquirentibus commented 2 weeks ago

Since you're using Visual Studio 2022 there have to be some logs somewhere and a stacktrace for that crash. In Debug it should hit the error in some sort of breakpoint as well, right? Can you share those with us? It's fine to just dump the whole logfile on us. (or send it to stefan@sentry.io if you have some stuff in there that you're not comfortable sharing here)

The problem with trying to debug a startup crash with VS2022 on IOS is that the IOS app will just Terminate after a few seconds after showing an exception in Visual Studio .. so it's difficult to even copy the exception.

One of the app's screens has a Massive number of controls and takes 3 seconds to load (less on latest iPhones) so realistically I'd have trouble getting the users to test a debug version anyway as they really complain about anything over 3 seconds?

I may try to progressively cut out parts of the app (in a test folder) over time to see what causes the issue but .. I just don't have the time to just focus on that right now. In my limited test with a Release using Sentry .. we're not seeing any exceptions at all so when I roll it out to more users .. if I encounter something I really need the debug version for .. I'll focus on figuring that out?

I do almost all of my testing between releases with the Windows version of the app. Other than a few special cases .. that works well and if Sentry can just point me towards the function where an unhandled exception occurs (probably a situation with horrible connectivity) .. that will point me in the right direction.

Possibly just commenting out all Serilog code and not importing the Serilog library will fix things .. and I'll keep working at it slowly.

But if there are no Obvious mistakes to look for with IOS/Sentry/Debugging .. I'll put getting the Debug version working on the back burner for now.

Thanks!!

getsentry / sentry-dotnet