[libart.so] art::ConditionVariable::WaitHoldingLocks

[momer9455]

[READ] Step 1: Are you in the right place?

Issues filed here should be about bugs in the code in this repository.
If you have a general question, need help debugging, or fall into some
other category use one of these other channels:

• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the firebase-talk
  google group.
• For help troubleshooting your application that does not fall under one
  of the above categories, reach out to the personalized
  Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Hedgehog | 2023.1.1 Patch 1
• Project Target SDK : 34
• Firebase Component:
• firebase-bom = "com.google.firebase:firebase-bom:30.3.2"
  firebase-crashlytics = { module = "com.google.firebase:firebase-crashlytics" }
  firebase-analytics = { module = "com.google.firebase:firebase-analytics-ktx" }
  firebase-performance = { module = "com.google.firebase:firebase-perf-ktx" }
  firebase-messaging = { module = "com.google.firebase:firebase-messaging-ktx" }
• Component version: (firebase-bom:30.3.2)

[REQUIRED] Step 3: Describe the problem

We are facing this issue on Android 14 devices only, reported on Playstore. Looks like it's related to Firebase library as I can't find these traces on Firebase crashlytics. Mainly the ANRs are coming on OPPO, realme, OnePlus and Vivo devices only.

Steps to reproduce:

Not able to reproduce it in-house with stock devices. Only real users are facing this which we can't track how they are getting this issue.

Relevant Code:

Following is the attached full stack trace log.
stacktrace.log

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[sasikumar-kuppusamy]

Hi Team,
We are also facing same ANRs in our apps after providing Android 14 support. Even though getting ANRs in all device models, majorly facing in Oppo, Vivo, Xiaomi, Samsung, Realme devices.

Project Target SDK : 34

Firebase dependency:
implementation platform("com.google.firebase:firebase-bom:33.3.0")
implementation 'com.google.firebase:firebase-messaging'
implementation 'com.google.firebase:firebase-crashlytics-ktx'
implementation 'com.google.firebase:firebase-analytics-ktx'
implementation 'com.google.firebase:firebase-perf-ktx'

We are facing this type ANRs even when the device is in idle state without any actions

Stack trace details:

(native):tid=914 systid=914 
#00 pc 0x99ccc libc.so (syscall + 28) (BuildId: a87e89fc2c0a5753053f536add4d7ae1)
#01 pc 0x22a220 libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*) + 136) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#02 pc 0x22c6c0 libart.so (art::Thread::FullSuspendCheck(bool) + 892) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#03 pc 0x990268 libart.so (artTestSuspendFromCode + 140) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#04 pc 0x37899c libart.so (art_quick_test_suspend + 156) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#05 pc 0x418250 boot.oat (art_jni_trampoline + 224)
#06 pc 0x61e870 boot.oat (java.lang.reflect.Method.equals + 160)
#07 pc 0x6b9cac boot.oat (libcore.reflect.AnnotationFactory.invoke + 556)
#08 pc 0x50adac boot.oat (java.lang.reflect.Proxy.invoke + 92)
#09 pc 0x362a40 libart.so (art_quick_invoke_static_stub + 640) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#10 pc 0x359408 libart.so (art::InvokeProxyInvocationHandler(art::ScopedObjectAccessAlreadyRunnable&, char const*, _jobject*, _jobject*, std::__1::vector<jvalue, std::__1::allocator<jvalue> >&) + 632) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#11 pc 0x35612c libart.so (artQuickProxyInvokeHandler + 960) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#12 pc 0x378bac libart.so (art_quick_proxy_invoke_handler + 76) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#13 pc 0xe0c84c boot.oat (android.view.ViewDebug.flagsToString + 652)
#14 pc 0xfe36cc boot.oat (android.view.WindowManager$LayoutParams.toString + 2940)
#15 pc 0xfe2b34 boot.oat (android.view.WindowManager$LayoutParams.toString + 52)
#16 pc 0x59d958 boot.oat (java.lang.StringBuilder.append + 72)
#17 pc 0xf39fb0 boot.oat (android.view.ViewRootImpl.relayoutWindow + 4560)
#18 pc 0xf34220 boot.oat (android.view.ViewRootImpl.performTraversals + 5472)
#19 pc 0xf3fec8 boot.oat (android.view.ViewRootImpl.doTraversal + 216)
#20 pc 0xe1150c boot.oat (android.view.ViewRootImpl$TraversalRunnable.run + 60)
#21 pc 0xded838 boot.oat (android.view.Choreographer.doCallbacks + 1128)
#22 pc 0xdeea10 boot.oat (android.view.Choreographer.doFrame + 3840)
#23 pc 0xeb9c78 boot.oat (android.view.Choreographer$FrameDisplayEventReceiver.run + 88)
#24 pc 0xbfbb5c boot.oat (android.os.Handler.dispatchMessage + 76)
#25 pc 0xc033f0 boot.oat (android.os.Looper.loopOnce + 1408)
#26 pc 0xc02dbc boot.oat (android.os.Looper.loop + 1196)
#27 pc 0x87e234 boot.oat (android.app.ActivityThread.main + 2532)
#28 pc 0x362a40 libart.so (art_quick_invoke_static_stub + 640) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#29 pc 0x35e42c libart.so (_jobject* art::InvokeMethod<(art::PointerSize)8>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long) + 732) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#30 pc 0x6c8cb8 libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277) + 32) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#31 pc 0x41e9c4 boot.oat (art_jni_trampoline + 116)
#32 pc 0xea2834 boot.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 132)
#33 pc 0xeb1a10 boot.oat (com.android.internal.os.ZygoteInit.main + 4816)
#34 pc 0x362a40 libart.so (art_quick_invoke_static_stub + 640) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#35 pc 0x34df38 libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*) + 204) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#36 pc 0x34beec libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list) + 512) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#37 pc 0x739d34 libart.so (art::JNI<true>::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list) + 104) (BuildId: 3b4ed3e67a9a04e3a37d259cd59da05b)
#38 pc 0xe0ca8 libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...) + 104) (BuildId: e1700cb9ee098d5866c2a2aab8a92b45)
#39 pc 0xed46c libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool) + 956) (BuildId: e1700cb9ee098d5866c2a2aab8a92b45)
#40 pc 0x254c app_process64 (main + 1260) (BuildId: dc9f8c722bcd83e891c665173591edd7)
#41 pc 0x96158 libc.so (__libc_init + 104) (BuildId: a87e89fc2c0a5753053f536add4d7ae1)

[lehcar09]

Hi @momer9455 and @sasikumar-kuppusamy, thank you for reaching out. Based on the logs you shared, it looks like the ANR issue is due to behavioral changes in Android 14.

This has been reported in #6147 and our engineers are already working on this along with other improvements for API level 34 (android 14), and it should be rolled out across all Firebase Android SDKs soon.

com.google.android.datatransport/transport-runtime library is using JobScheduler which is not recommended now as mentioned in android documentation: https://developer.android.com/about/versions/14/behavior-changes-14

JobScheduler reinforces callback and network behavior
Since its introduction, JobScheduler expects your app to return from onStartJob or onStopJob within a few seconds. Prior to Android 14, if a job runs too long, it stops and fails silently. If your app targets Android 14 (API level 34) or higher and exceeds the granted time on the main thread, the app triggers an ANR with the error message "No response to onStartJob" or "No response to onStopJob". Consider migrating to WorkManager, which provides support for asynchronous processing or migrating any heavy work into a background thread.

To streamline the updates, you can follow on the issue #6147. With that, I'll be closing this issue now. Thanks.