FetchProvidersForEmailAsync crash when accessing to provider list

[archengineer]

[REQUIRED] Please fill in the following fields:

• Unity editor version: 2018.4.28
• Firebase Unity SDK version: 6.15.2
• Source you installed the SDK: Unity Package Manager
• Problematic Firebase Component: Auth
• Other Firebase Components in use: Auth, Remote Config
• Additional SDKs you are using: Facebook, One Signal
• Platform you are using the Unity editor on: Windows
• Platform you are targeting: iOS, Android
• Scripting Runtime: IL2CPP

[REQUIRED] Please describe the issue here:

We started to see too much crashes on Crashlytics for iOS after we started to use Firebase FetchProvidersForEmailAsync method.
We inserted Crashlytics logs and we see that whenever user calls FetchProvidersForEmailAsync method and use an task result list, game crashes. The game crash even when we just loop with foreach on task result for providers.

Here is the code we use:

            var firebaseAuth = FirebaseAuth.DefaultInstance;
            firebaseAuth.FetchProvidersForEmailAsync(email).ContinueWithOnMainThread(fetchTask =>
            {
                if (fetchTask.IsCanceled)
                {
                    onCheckEmailComplete.SafeInvoke(false, false);
                }
                else if (fetchTask.IsFaulted)
                {
                    onCheckEmailComplete.SafeInvoke(false, false);
                }
                else if (fetchTask.IsCompleted)
                {
                    Crashlytics.Log("CheckUserEmailExist Task Completed");

                    bool isUserExist = false;

                    if (fetchTask.Result != null)
                    {
                        foreach (string provider in fetchTask.Result)
                        {
                            isUserExist = true;
                        }
                    }

                    onCheckEmailComplete.SafeInvoke(true, isUserExist);
                }
            });

Here is the stack trace from Firebase Crashlytics:

Crashed: com.apple.main-thread
0 match3d 0x1061863ac Firebase_App_StringList_getitem + 46656
1 match3d 0x106a90d88 -[VNGFMDatabase initWithPath:].cold.1 + 4370992520
2 match3d 0x106a926b4 -[VNGFMDatabase initWithPath:].cold.1 + 4370998964
3 match3d 0x1064bbc5c -[VNGFMDatabase initWithPath:].cold.1 + 4364876892
4 match3d 0x106af2c84 -[VNGFMDatabase initWithPath:].cold.1 + 4371393668
5 match3d 0x106af2868 -[VNGFMDatabase initWithPath:].cold.1 + 4371392616
6 match3d 0x106aa6e14 -[VNGFMDatabase initWithPath:].cold.1 + 4371082772
7 match3d 0x106aa6d5c -[VNGFMDatabase initWithPath:].cold.1 + 4371082588
8 match3d 0x106aa8214 -[VNGFMDatabase initWithPath:].cold.1 + 4371087892
9 match3d 0x10492d14c RuntimeInvoker_TrueVoid_t22962CB4C05B1D89B55A6E1139F0E87A90987017(void ()(), MethodInfo const, void*, void**) + 51122 (Il2CppInvokerTable.cpp:51122)
10 match3d 0x1060b55c0 il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) + 584 (Runtime.cpp:584)
11 match3d 0x105acac5c scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) + 247 (ScriptingApi_Il2Cpp.cpp:247)
12 match3d 0x105ad3c18 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) + 347 (ScriptingInvocation.cpp:347)
13 match3d 0x105ade5f4 MonoBehaviour::CallUpdateMethod(int) + 578 (MonoBehaviour.cpp:578)
14 match3d 0x10594f07c void BaseBehaviourManager::CommonUpdate() + 178 (Behaviour.cpp:178)
15 match3d 0x105a2e0f4 ExecutePlayerLoop(NativePlayerLoopSystem*) + 347 (PlayerLoop.cpp:347)
16 match3d 0x105a2e128 ExecutePlayerLoop(NativePlayerLoopSystem*) + 365 (PlayerLoop.cpp:365)
17 match3d 0x105a2e308 PlayerLoop() + 45 (RecursionLimit.h:45)
18 match3d 0x105cb39d4 UnityPlayerLoopImpl(bool) + 272 (LibEntryPoint.mm:272)
19 match3d 0x1047e618c UnityRepaint + 285 (UnityAppController+Rendering.mm:285)
20 match3d 0x1047e6068 -[UnityAppController(Rendering) repaintDisplayLink] + 72 (UnityAppController+Rendering.mm:72)
21 QuartzCore 0x19528a748 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 664
22 QuartzCore 0x195361244 display_timer_callback(__CFMachPort*, void*, long, void*) + 280
23 CoreFoundation 0x191fcbce4 __CFMachPortPerform + 176
24 CoreFoundation 0x191ff0098 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 60
25 CoreFoundation 0x191fef440 __CFRunLoopDoSource1 + 596
26 CoreFoundation 0x191fe9320 __CFRunLoopRun + 2360
27 CoreFoundation 0x191fe84bc CFRunLoopRunSpecific + 600
28 GraphicsServices 0x1a8afa820 GSEventRunModal + 164
29 UIKitCore 0x194995164 -[UIApplication _run] + 1072
30 UIKitCore 0x19499a840 UIApplicationMain + 168
31 match3d 0x1047dd660 main + 41 (main.mm:41)
32 libdyld.dylib 0x191cafe40 start + 4

Relevant Code:

            var firebaseAuth = FirebaseAuth.DefaultInstance;
            firebaseAuth.FetchProvidersForEmailAsync(email).ContinueWithOnMainThread(fetchTask =>
            {
                if (fetchTask.IsCanceled)
                {
                    onCheckEmailComplete.SafeInvoke(false, false);
                }
                else if (fetchTask.IsFaulted)
                {
                    onCheckEmailComplete.SafeInvoke(false, false);
                }
                else if (fetchTask.IsCompleted)
                {
                    Crashlytics.Log("CheckUserEmailExist Task Completed");

                    bool isUserExist = false;

                    if (fetchTask.Result != null)
                    {
                        foreach (string provider in fetchTask.Result)
                        {
                            isUserExist = true;
                        }
                    }

                    onCheckEmailComplete.SafeInvoke(true, isUserExist);
                }
            });

[patm1987]

Hi @archengineer ,

For clarity: how often do you see this crash? Is it something that happens all the time and have you captured it locally, or do you only see it on some percent of your playerbase?

If it's something you can reproduce regularly, can you get it to occur in the auth test app?

[archengineer]

Hi @patm1987,

We cant reproduce it locally unfortunately. But we are seeing this crash on live users in Crashlytics. This crash affects almost %5 of our live users and it is too much. (4000 crash per day)

Thanks.

[patm1987]

In my investigation, I can't find a definitive bug or fix that might have happened. It looks like you're roughly hitting FetchProvidersForEmail which returns a struct that effectively wraps a std::vector<std::string>. Iterating over this (It gets exposed to C# as an IEnumerator<string> - the StringList in your callstack) seems to be causing an issue.

This would be much easier to track down if you could reproduce this locally. My top recommendation would be to see if you can test with 6.16.1 (I do believe that, among other things, there have been fixes to future which perhaps the frequency you're seeing this issue is indicative of a threading issue?).

Likewise, if you manage to reproduce it in the Auth Quickstart, that would do a lot to make sure we find the bug itself and can work on and verify a fix.

Other than that, is there anything you can gleam from Crashlytics' reporting? Is there a specific iOS device or OS version that crashes more (or is absent in your crashes)? In the event log breadcrumbs leading up to a crash in the dashboard, do you see any other consistent behaviour that can be useful?

Finally: this is a public forum. If you'd be more comfortable sharing game metrics in private, feel free to file a bug report and reference this GitHub issue in it. They will also have additional support tools that might help.

[archengineer]

Hi,

I have updated firebase to latest version. Also I have tried all the ways to fix this issue on the link of firebase blog: https://firebase.googleblog.com/2019/07/firebase-and-tasks-how-to-deal-with.html.

None of them worked for me. The crash still exist. Finally I use "Count()" method on "FetchProvidersForEmailAsync" result and it worked. But I think this is an error because I can't reach the provider list if I want to. I only know if the user exist or not from provider list count right now.

I can't reproduce the issue right now. But if I can I will open a new ticket for this.

Thanks.

[chkuang-g]

Hi @archengineer,

TL;DR; Please read the part starting with "If this theory is correct".

Taking a look of the code, this seems to be an issue related to race with GC (Garbage Collection).

Here is the implementation of FetchProvidersForEmailAsync()

  public System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable<string>>
      FetchProvidersForEmailAsync(string email) {
    ThrowIfNull();
    System.Threading.Tasks.TaskCompletionSource<System.Collections.Generic.IEnumerable<string>>
        taskCompletionSource =
        new System.Threading.Tasks.TaskCompletionSource<
          System.Collections.Generic.IEnumerable<string>>();
    System.Threading.Tasks.Task<Firebase.Auth.FetchProvidersResult> task =
        FetchProvidersForEmailInternalAsync(email);
    task.ContinueWith(t => taskCompletionSource.SetResult(t.Result.Providers));
    return taskCompletionSource.Task;
  }

FetchProvidersForEmailInternalAsync() is a wrapper around the C++ implementation. And t.Result.Providers is a StringList, which is a C# wrapper around C++ std::vector<std::string>.

I think the problem is that the Task returned by FetchProvidersForEmailAsync() is referencing the StringList from FetchProvidersResult. After FetchProvidersForEmailInternalAsync() is finished, FetchProvidersResult would be GCed. The StringList will be disposed and contains invalid C pointer. And I assume the GC from a release build would be much much more aggressive.

If this theory is correct, that means

• You might be able to reproduce the crash by making release build and test locally
• You might be able to workaround with this issue by using ContinueWith instead of ContinueWithOnMainThread, which introduces additional delay for GC to kick-in. Just be aware that you cannot use any Unity API within the continuation block for ContinueWith since it is called from a non-main thread. Crashlytics.Log() should be totally fine.

Could you try these and see if you can reproduce the crash or avoid the issue by using ContinueWith?

Thanks!
Shawn