Login/Register
Xamarin App Crashes On Launch After Not Being Opened For A Day
Asked Answered
Solved iosxamarinxamarin.formsxamarin.iosbearer-token
T

1

8

My Xamarin project runs a simple token identification check on launch, which is where I believe it is being held up. The odd part is that it only crashes after not being opened for an extended period of time, like after 24 hours. No error is shown and the crash isn't fatal as you can still see it running in the background, but it won't launch. Once this initial error occurs, and the app is removed from the background, it launches and runs fine. [I previously posted regarding a similar (possibly the same) issue][1], but when that occurred, it would result in a crash as well as a crash report. It stopped 'crashing' after changing the iOS linker settings. [The code executed at launch can also be seen in a code review thread.][2] I don't understand why this is happening, the token is definitely not expired because they are set to expire 14 days after issuing. I'm using Azure for all backend and the web API is an ASP.NET project hosted on a free testing web hosting plan.

Crashlog:

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Region Info: 0 is not in any region.  Bytes before following region: 4336173056
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                 000000010274c000-0000000102794000 [  288K] r-x/r-x SM=COW  ...co.Mobile.iOS

Triggered by Thread:  0

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x00000001be530df0 __pthread_kill + 8
1   libsystem_pthread.dylib         0x00000001be450948 pthread_kill + 228 (pthread.c:1458)
2   libsystem_c.dylib               0x00000001be3dfc24 __abort + 116 (abort.c:147)
3   libsystem_c.dylib               0x00000001be3dfbb0 abort + 116 (abort.c:118)
4   Ecco.Mobile.iOS                 0x0000000105209d8c xamarin_initialize.cold.1 + 0
5   Ecco.Mobile.iOS                 0x00000001052014a8 xamarin_printf + 44782760 (runtime.m:2468)
6   Ecco.Mobile.iOS                 0x0000000105118f80 mono_invoke_unhandled_exception_hook + 43831168 (exception.c:1299)
7   Ecco.Mobile.iOS                 0x00000001050ba76c mono_handle_exception_internal + 43444076 (mini-exceptions.c:2783)
8   Ecco.Mobile.iOS                 0x00000001050b9154 mono_handle_exception + 43438420 (mini-exceptions.c:3107)
9   Ecco.Mobile.iOS                 0x00000001050b0478 mono_arm_throw_exception + 43402360 (exceptions-arm64.c:401)
10  Ecco.Mobile.iOS                 0x0000000102ba7a7c throw_exception + 172
11  Ecco.Mobile.iOS                 0x00000001029180fc System_Runtime_ExceptionServices_ExceptionDispatchInfo_Throw + 44
12  Ecco.Mobile.iOS                 0x000000010291f924 System_Runtime_CompilerServices_AsyncMethodBuilderCore__c__ThrowAsyncb__7_0_object + 84
13  Ecco.Mobile.iOS                 0x0000000103880e3c Foundation_NSAsyncSynchronizationContextDispatcher_Apply + 18042428 (NSAction.cs:178)
14  Ecco.Mobile.iOS                 0x0000000102b640f0 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
15  Ecco.Mobile.iOS                 0x00000001050caab4 mono_jit_runtime_invoke + 43510452 (mini-runtime.c:3165)
16  Ecco.Mobile.iOS                 0x0000000105163b9c mono_runtime_invoke_checked + 44137372 (object.c:3220)
17  Ecco.Mobile.iOS                 0x0000000105167004 mono_runtime_invoke + 44150788 (object.c:3107)
18  Ecco.Mobile.iOS                 0x0000000102754514 native_to_managed_trampoline_18(objc_object*, objc_selector*, _MonoMethod**, unsigned int) + 34068 (registrar.m:776)
19  Ecco.Mobile.iOS                 0x0000000102755578 -[__MonoMac_NSAsyncSynchronizationContextDispatcher xamarinApplySelector] + 38264 (registrar.m:7896)
20  Foundation                      0x00000001beb4ef94 __NSThreadPerformPerform + 188 (NSThread.m:807)
21  CoreFoundation                  0x00000001be6c4d14 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1922)
22  CoreFoundation                  0x00000001be6c4c68 __CFRunLoopDoSource0 + 84 (CFRunLoop.c:1956)
23  CoreFoundation                  0x00000001be6c43c4 __CFRunLoopDoSources0 + 188 (CFRunLoop.c:1992)
24  CoreFoundation                  0x00000001be6bf1fc __CFRunLoopRun + 780 (CFRunLoop.c:2882)
25  CoreFoundation                  0x00000001be6bebc8 CFRunLoopRunSpecific + 480 (CFRunLoop.c:3192)
26  GraphicsServices                0x00000001c8aa05cc GSEventRunModal + 164 (GSEvent.c:2246)
27  UIKitCore                       0x00000001c2871744 UIApplicationMain + 1936 (UIApplication.m:4823)
28  Ecco.Mobile.iOS                 0x00000001038dfa98 wrapper_managed_to_native_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 344
29  Ecco.Mobile.iOS                 0x000000010382a500 UIKit_UIApplication_Main_string___intptr_intptr + 17687808 (UIApplication.cs:86)
30  Ecco.Mobile.iOS                 0x000000010382a484 UIKit_UIApplication_Main_string___string_string + 17687684 (UIApplication.cs:66)
31  Ecco.Mobile.iOS                 0x0000000102796334 Ecco_Mobile_iOS_Application_Main_string__ + 303924 (/<unknown>:1)
32  Ecco.Mobile.iOS                 0x0000000102b640f0 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
33  Ecco.Mobile.iOS                 0x00000001050caab4 mono_jit_runtime_invoke + 43510452 (mini-runtime.c:3165)
34  Ecco.Mobile.iOS                 0x0000000105163b9c mono_runtime_invoke_checked + 44137372 (object.c:3220)
35  Ecco.Mobile.iOS                 0x0000000105168c94 mono_runtime_exec_main_checked + 44158100 (object.c:5284)
36  Ecco.Mobile.iOS                 0x00000001050affe0 mono_jit_exec + 43401184 (driver.c:1328)
37  Ecco.Mobile.iOS                 0x0000000105208238 xamarin_main + 44810808 (monotouch-main.m:0)
38  Ecco.Mobile.iOS                 0x0000000102796290 main + 303760 (main.m:312)
39  libdyld.dylib                   0x00000001be53b384 start + 4

Full stack trace: https://pastebin.com/VXHHdjdz

Tattan answered 18/11, 2020 at 4:4 Comment(7)
If you set link to All,does it crash ? – Brummell
@LeoZhu-MSFT Now that I think of it, it would probably result in the crash stated above. – Tattan
did you added any of Crash Analytics in your app? try adding one & trace the actual crash report. You can try App Center Analytics. And for me, i had the same issue but it maybe of different cause for you, i had an extra symbol present in my xaml file, so my app use to crash at startup in Release mode only, worked fine on Debug mode – Irisirisa
@Blu I am using TestFlight so I did receive crashlogs. Here is the crash #64160638 – Tattan
I don't think that anyone can answer based on the data above. But if you are willing to provide the code under the freelancer contract, I don't see what is the problem in fixing it. Obviously there might be problems on your server so the app may not start with logged in user, but it shouldn't crash. – Longford
Can you repost the Pastebin? It says, "This page is no longer available". – Polack
@Polack edited the link, should work now – Tattan
H
6

You mentioned that you're using a webapi on a free test plan. I have been using the same plan for a Project that I'm working on, and I've noticed that the first time I launch the app after extended periods of time (like the next day for example) the backend app has shut down in the meantime due to the lack of activity, and it's dependencies (like a serverless SQL instance) do too.

When the first request comes in, the API has to start up, then the SQL instance also has to start up. The two combined take long enough that the first request basically always fails spectacularly, but then the next one after works fine.

It sounds like something similar might be happening here. The Xamarin framework (also something I've been working with for a couple of years) has been... Interesting... In how it deals with some exceptions.

Anyway, I have something which may be a solution, depending on if that is the problem. Try making requests on the API just before trying to reawaken the app, and then see if it resumes properly. If it does, you might need to fiddle with your App Service settings to enable the application to be "Always On".

this was originally a comment but blasted way past the character limit so I figured it was worth a shot as an answer.

Hybrid answered 19/12, 2020 at 16:16 Comment(2)
This sounds way too similar to my issue, I believe this could possibly be it!!! I'm going to test this out and get back to you. Thank you in the meantime!! – Tattan
So I upgraded my web app plan to not have daily compute limitations, but still have the crash. I'm willing to bet this is the issue and it's related to other services as well. I have to look into it more, so I'm going to mark this as correct in the meantime. I will update if I find out anymore information. – Tattan

© 2022 - 2024 — McMap. All rights reserved.