App crashes when returning to app from background [main/xamarin_main/monotouch-main/etc.)

[JCzubkowskiTrek]

Description

Our app is encountering a nondescript exception when a user is returning to the app after it has been in the background and they bring it back into the foreground. This issue is reproduced most reliably after the app has been in the background for >= 30 minutes. The crash occurs almost immediately after the app is put into foreground (<= .5 seconds). Stack trace from crashlytics is below in ‘relevant log output’.

This is happening in production, and is reproducable in lower testing environments. We have a phased rollout starting at 1% of our user base and these are the stats:

This issue has 351 crash events affecting 240 users.

Additional info: In searching for similar issues and potential solutions, we came across suggestions to inspect usage of background tasks. Our app is only implementing background mode of remote notifications, not background fetch nor background processing.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.61 SR6.1

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

iOS 17.5.1, 16.3.1, 15.4.1, 15.5.0, 18, 16.1.1, 16.6.1, 17.3.1, 17.4.1, 17.1.2, 17.6.0, 17.2.1, 16.7.8, 16.0.2

Did you find any workaround?

No helpful workarounds at this time. Attempted fixes are:

1. We attempted to fix by cancelling all scheduled tasks during OnStopped event, thinking these processes were causing the crash upon re-entry to the app. This, however, did not help.
2. Added the following code to .csproj, hoping to get more detailed logs. We reproduced the crash, but logs in crashlytics looked the same.

   <PropertyGroup>
   <NoSymbolStrip>true</NoSymbolStrip>
   </PropertyGroup>

Relevant log output

Crashed: tid_103
0  libsystem_kernel.dylib         0xc42c __pthread_kill + 8
1  libsystem_pthread.dylib        0x7c0c pthread_kill + 268
2  libsystem_c.dylib              0x75ba0 abort + 180
3  ProjectName                    0xded20 xamarin_find_protocol_wrapper_type + 1201 (runtime.m:1201)
4  ProjectName                    0x2e9218 mono_invoke_unhandled_exception_hook + 1263 (exception.c:1263)
5  ProjectName                    0x383d04 mono_jit_exec + 1375 (driver.c:1375)
6  ProjectName                    0xe7344 xamarin_main + 495 (monotouch-main.m:495)
7  ProjectName                    0x3ebe20 main + 81 (main.arm64.mm:81)
8  ???                            0x1c6221e4c (Missing)

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• [iOS] Crash in production: .NET ThreadPool Worker EXC_BAD_ACCESS KERN_INVALID_ADDRESS (#17626), similarity score: 0.76
• Crash when app is deployed with dotnet publish (#20981), similarity score: 0.74
• iOS app crashes on startup after distributing through TestFlight (#17405), similarity score: 0.74
• Crash on Android when hold app over 2 minutes in background (#22284), similarity score: 0.74
• [iOS} Crashed: tid_103 EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000 (#23235), similarity score: 0.73

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[PureWeen]

@rolfbjarne @dalexsoto thoughts?

[BrandanN21]

Some additional information to provide to this issue.

When using a physical device reproducing this crash and having the console app connected to view logs we receive this at the time of the crash.

Looking in our Android Crashlytics it is interesting because we are seeing a crash that is very similar to what we see on iOS now that we have a little more insight / detail.

MauiApplication.n_onCreate Fatal Exception: android.runtime.JavaProxyThrowable System.AggregateException: Retry failed after 4 tries. Retry settings can be adjusted in ClientOptions.Retry or by configuring a custom retry policy in ClientOptions.RetryPolicy. (hostname nor servname provided, or not known [azure app config connection string]

In our code we aren't calling into this app configuration service which is interesting to us that it is failing to call out to it when we are resuming the app to the foreground?

With the onResume() lifecycle event is there any sort of re-initialization that occurs for the app that could be causing issues related to network?

[BrandanN21]

@rolfbjarne @PureWeen @dalexsoto

We have removed anything that could potentially be running in the background - even removed the calls out to our azure app config service in case that was causing issues. We are still inconsistently getting this crash between iOS test devices.

Do you have any thoughts that could help us narrow this down? Is this a potential bug in MAUI when resuming applications that have been in the background for 'x' amount of time? We know that the OS will kill the app at some point due to resources but that is not an issue, when the app is killed by the OS it starts up 'fresh' as we would expect with the splash screen. This is only happening when we resume the app from the background, most often it crashes when it's been in the background longer than 30 minutes, but not every time.

We don't have any luck consistently reproducing the issue, it seems to be sporadic and inconsistent across multiple iOS devices that we've used to test.

Any insight would be greatly appreciated, thanks!

[BrandanN21]

@PureWeen

We are using maui 8.0.61 from the nuget feed right now. We found this in the change log for 8.0.70 SR. We updated to the 8.0.70 package yesterday and ran some testing.

https://github.com/dotnet/maui/releases/tag/8.0.70#:~:text=%5BiOS%5D%20Crash%20upon%20resuming%20the%20app%20%2D%20fix%20by%20%40kubaflo%20in%20%2323360

We were still able to reproduce the crash. Is someone on the MAUI team able to confirm if this is still an issue, or able to provide some assistance identifying if this is still a bug in MAUI?

[JCzubkowskiTrek]

Hi @rolfbjarne @PureWeen @dalexsoto, We’re still struggling to wrap our heads around this issue fully. Do you have any thoughts about this issue? Our team has exhausted all known paths for an evidence-based solution, so we’re hoping to reinvigorate the effort to fix this if there are more avenues we can or should try. If there are more details we can provide, please let myself and @BrandanN21 know. We’ll keep you updated with any further developments on our side. Thank you!

[phillippschmedt]

@BrandanN21 @JCzubkowskiTrek Your issue could be related to the issue I am facing, see:

• https://github.com/xamarin/xamarin-macios/issues/20769
• https://github.com/dotnet/maui/issues/23882

For us the app seems to crash after being in the background for a while and then getting woke up by silent pushes. We struggle the same problem that we removed any code that we think could cause the problem and it still happens.

Do you have any full and symbolicated crash logs available from your crash? Does it maybe look similar to what I posted in the mentioned issues?

[rolfbjarne]

@JCzubkowskiTrek one idea would be to log all marshalled exceptions to disk, to see any of those might give a clue.

You can read about exception marshalling here: https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/ios/platform/exception-marshaling.md, and there are events you can subscribe to where you'd collect the exception information and log it: https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/ios/platform/exception-marshaling.md#events

[johnadali]

@rolfbjarne - thank you for your suggestion. We have added logging for marshalled exceptions as described in the links you provided. Unfortunately, we did not see these events firing when we reproduce the crashing problem so we were unable to gather any additional information.

@phillippschmedt - Our app isn't configured for silent pushes and we don't have anything sending push notifications to the app at the time it crashes. We do have symbolicated crash logs via Crashlytics but they don't seem to have any information that points us to anything useful. I am including one of the crash logs in the hope that you or someone can make more sense of this than we can. MauiCrashLog.txt

[rolfbjarne]

I am including one of the crash logs in the hope that you or someone can make more sense of this than we can. MauiCrashLog.txt

This is the important part, although it doesn't explain much:

2  libsystem_c.dylib              0x75ba0 abort + 180
3  ProjectName                   0xded20 xamarin_find_protocol_wrapper_type + 1201 (runtime.m:1201)
4  ProjectName                   0x2e9218 mono_invoke_unhandled_exception_hook + 1263 (exception.c:1263)
5  ProjectName                   0x383d04 mono_jit_exec + 1375 (driver.c:1375)
6  ProjectName                   0xe7344 xamarin_main + 495 (monotouch-main.m:495)
7  ProjectName                   0x3ebe20 main + 81 (main.arm64.mm:81)

Frame 3 is bogus, but the other ones are correct: the app crashes because of an unhandled exception.

Unfortunately it doesn't say anything about the exception itself, but you should be able to process it by changing your Main function to something like:

static void Main (string [] args)
{
    try {
        UIApplication.Main (args, null, typeof (AppDelegate));
    } catch (Exception e) {
        // Log information about 'e' here.
        throw; // throw exception again so that we get a crash report
    }
}

[johnadali]

@rolfbjarne - We have implemented your suggestion and we receive the following exception (when the crash occurs): exception: System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing. ---> System.TimeoutException: A task was canceled.

Is it possible that HttpClient implementation is causing this crash?

[rolfbjarne]

@rolfbjarne - We have implemented your suggestion and we receive the following exception (when the crash occurs): exception: System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing. ---> System.TimeoutException: A task was canceled.

Is it possible that HttpClient implementation is causing this crash?

A network request failed: the fix is to handle the exception wherever it occurs - printing the stack trace should help narrowing it down.

[johnadali]

@rolfbjarne - We have now obtained the stack trace when the crash is happening and this has led us to the are in our code where the crash is occurring. At this point we believe that we have a network request going out when our app is in the foreground that is not completing when we put it in the background. When we wait for a long time (we have been waiting 5-30 minutes) and then bring the app to the foreground again, this network request is trying to complete but the stack trace says it has timed out.

We are verifying this with additional testing.

[johnadali]

@rolfbjarne - We have verified that we had a network request that was taking a bit longer to execute and when this was still running we were putting the app in the background. Bringing the app back to the foreground after 100 seconds was causing the app to crash.

We have also verified that the task described above was not using the cancellation pattern that asynchronous programming supports so once we added that to our code the crash no longer occurred.

Thanks to all for the support with this - this thread can now be closed. Hopefully this will help someone in the future if they encounter a similar issue.