[Bug] [Android] Random JNI errors when calling provider_data() or uid() on a valid user right after initializing Auth.

Comienza en Auth::GetAuth y Auth::InitPlatformAuth; después, sigue JniAuthStateListener_nativeOnAuthStateChanged a través de Auth::UpdateCurrentUser y SetImplFromLocalRef. Ejecuta el acceso repetido notificado a User::uid() inmediatamente después de la inicialización; se considera terminado cuando el caso de estrés ya no produce errores JNI de referencia eliminada u objeto nulo y las propiedades de current_user siguen siendo utilizables.

[REQUIRED] Please fill in the following fields:

• Pre-built SDK from the website or open-source from this repo: prebuilt release
• Firebase C++ SDK version: 12.4.0 (already happened with Firebase C++ SDK 11.0.1)
• Problematic Firebase Component: Auth
• Other Firebase Components in use: Analytics, Crashlytics, Firestore, Functions, RemoteConfig
• Platform you are using the C++ SDK on: Mac
• Platform you are targeting: Android

[REQUIRED] Please describe the issue here:

Crashlytics reports some random crashes a few seconds after startup, during the initialization of our app, when accessing the state of a previously signed in user.
The stacks look like this:

JNI DETECTED ERROR IN APPLICATION: use of deleted global reference 0x3886

  #00  pc 0x000000000008cdd0  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
  #01  pc 0x000000000053b0a4  /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2340)
  #02  pc 0x000000000001394c  /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+76)
  #03  pc 0x00000000000130cc  /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+312)
  #04  pc 0x0000000000372930  /apex/com.android.art/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+2596)
  #05  pc 0x0000000000372aa0  /apex/com.android.art/lib64/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+188)
  #06  pc 0x000000000058edbc  /apex/com.android.art/lib64/libart.so (art::Thread::DecodeJObject(_jobject*) const+740)
  #07  pc 0x00000000005335bc  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithVarArgs<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, std::__va_list)+72)
  #08  pc 0x0000000000533918  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+92)
  #09  pc 0x000000000038ca54  /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list)+656)
  #10  pc 0x0000000001efb0a8  /data/app/~~we2dODBK-dwTNyJ0WwgHVw==/XXX-PL2uZARhnKyZj-sBR8U9ag==/split_config.arm64_v8a.apk!libgame_android.so (_JNIEnv::CallObjectMethod(_jobject*, _jmethodID*, ...)+116) (BuildId: 49d308be143cc46526a72431ce8b6942c800f328)
  #11  pc 0x0000000001db7500  /data/app/~~we2dODBK-dwTNyJ0WwgHVw==/XXX-PL2uZARhnKyZj-sBR8U9ag==/split_config.arm64_v8a.apk!libgame_android.so (firebase::auth::User::provider_data() const+112) (BuildId: 49d308be143cc46526a72431ce8b6942c800f328)

it varies a bit and sometimes the JNI error is : JNI DETECTED ERROR IN APPLICATION: obj == null
Also, sometimes it will crash in firebase::auth::User::uid() instead, there is a call right after provider_data().

Our crash is very similar to this issue, but note that we are not registering any AuthStateListener ourselves: https://github.com/firebase/firebase-cpp-sdk/issues/753

Steps to reproduce:

Have you been able to reproduce this issue with just the Firebase C++ quickstarts ?
No, rate seems low: about 1 crash per day per 10000 users.

Relevant code

Here is what happens on app launch:
Our app starts by initializing the firebase app
firebase::App::Create(env, _activity->clazz);

then about 1 second later, we initialize Auth and try to retrieve some data if the user is signed in

    auth::Auth *auth = auth::Auth::GetAuth(App::GetInstance());           << First call of GetAuth
    auth::User user = auth->current_user();
    if (!user.is_valid())
        return;

    std::vector<auth::UserInfoInterface> data = user.provider_data();     << Crash here
    ...

All our calls to Auth are done from the same native cpp thread.

Investigation:

By looking at the SDK code, it seems this crash could happen if there is a data race where a thread calls Auth::UpdateCurrentUser (more specifically SetImplFromLocalRef(env, j_user, &auth_data->user_impl)) while our native thread is accessing the current_user's properties.

Potential culprit:

From my understanding, the initialization of Auth will synchronously call UpdateCurrentUser, so accessing the user right after should be fine.
But what I also noticed is that Auth::InitPlatformAuth will register a JniAuthStateListener.
I believe addAuthStateListener from FirebaseAuth.java will trigger a callback from a Java Thread after a random delay, which will eventually result in a call to JniAuthStateListener_nativeOnAuthStateChanged and Auth::UpdateCurrentUser from another thread, resulting in a data race.

I was not able to reproduce the crash with the production code, but I was able to get it by calling User::uid() many times right after the init of Auth. Something like this:

    auth::Auth *auth = auth::Auth::GetAuth(App::GetInstance());
    auth::User user = auth->current_user();
    if (!user.is_valid())
        return;

    for (int i = 0; i < 1000000; i++)
        user.uid();
    ...

This generates a crash similar to the one we see in production. It happens around every 5 to 10 app launches. I couldn't get it to crash with user.provider_data() though, maybe it's just less likely because it has more instructions.
Also, I haven't been able to generate the crash when Auth is initialized about 1s before the first user access.

Other notes:

• We have never seen this crash on other calls to User::uid() or User::provider_data(), only the ones right after the Auth initialization crashes.
• We also have an iOS version and have never seen any crash there when accessing a User's properties.