Android ART Native Crash sometimes occurs when changing a threads name
See original GitHub issue
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.- <<<
backtrace:
#00 pc 00000000000830f0 /apex/com.android.runtime/lib64/bionic/libc.so (abort+160)
#00 pc 00000000004b977c /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+2280)
#00 pc 000000000000b458 /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+580)
#00 pc 00000000005108a0 /apex/com.android.runtime/lib64/libart.so (art::ThreadSuspendByPeerWarning(art::Thread*, android::base::LogSeverity, char const*, _jobject*)+656)
#00 pc 000000000050fa80 /apex/com.android.runtime/lib64/libart.so (art::ThreadList::SuspendThreadByPeer(_jobject*, bool, art::SuspendReason, bool*)+1120)
#00 pc 000000000042fa88 /apex/com.android.runtime/lib64/libart.so (art::Thread_setNativeName(_JNIEnv*, _jobject*, _jstring*)+1076)
#00 pc 00000000000ba7e8 /system/framework/arm64/boot.oat (art_jni_trampoline+152)
#00 pc 00000000001a5468 /system/framework/arm64/boot.oat (java.lang.Thread.setName+120)
#00 pc 00000000002ff26c /data/app/com.-==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.setIndexInArray+284)
#00 pc 0000000000137334 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548)
#00 pc 0000000000145fec /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244)
#00 pc 00000000002e3948 /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+384)
#00 pc 00000000002deba8 /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+892)
#00 pc 00000000005a728c /apex/com.android.runtime/lib64/libart.so (MterpInvokeVirtualQuick+616)
#00 pc 0000000000135594 /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_virtual_quick+20)
#00 pc 00000000017d7a5e /data/app/com.-==/oat/arm64/base.vdex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.tryTerminateWorker+174)
#00 pc 00000000002b4c5c /apex/com.android.runtime/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.4579747295037710581)+240)
#00 pc 0000000000592688 /apex/com.android.runtime/lib64/libart.so (artQuickToInterpreterBridge+1032)
#00 pc 0000000000140468 /apex/com.android.runtime/lib64/libart.so (art_quick_to_interpreter_bridge+88)
#00 pc 00000000002fcd94 /data/app/com.-==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.park+180)
#00 pc 00000000002fe314 /data/app/com.-==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.tryPark+628)
#00 pc 00000000002fd984 /data/app/com-==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker+228)
#00 pc 00000000002ff128 /data/app/com.-==/oat/arm64/base.odex (kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run+40)
#00 pc 0000000000137334 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548)
#00 pc 0000000000145fec /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244)
#00 pc 00000000004b103c /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
#00 pc 00000000004b2150 /apex/com.android.runtime/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue const*)+416)
#00 pc 00000000004f2b18 /apex/com.android.runtime/lib64/libart.so (art::Thread::CreateCallback(void*)+1176)
#00 pc 00000000000e6890 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#00 pc 0000000000084b6c /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
Looking at the the art source it seems like this timeout when trying to set the thread name may be the culprit https://android.googlesource.com/platform/art/+/master/runtime/thread_list.cc#970
It’s not really clear to me whether this timeout would be triggered based on a specific state of the Thread or if it’s just a race condition that is sometimes triggered.
It seems like the thread name changing is mostly cosmetic? I wonder if an option to disable or reduce thread name changes might be a quick solution–as much as I would hate giving that up for debug purposes 😦
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:16 (5 by maintainers)
Top Results From Across the Web
Diagnosing Native Crashes | Android Open Source Project
The first name is the thread name, and the name surrounded by >>> and <<< is the process name.
Read more >Attaching a debugger sometimes causes the app to crash
I'm developing an Android application, and sometimes when attaching a debugger to the running app, after a while it causes it to crash....
Read more >Native Crash Google in 'com.google.android.gms:play ...
I have seen that PublisherAdRequest and PublisherAdView are both now deprecated. But I'm not sure about the reasons or if the deprecation is...
Read more >How to make sense of Android crash logs | Bugsnag Blog
The visible effect of this is that an app has 'frozen' from a user's perspective, which can be immensely frustrating. Common causes include ......
Read more >Collecting the Garbage: A brief history of GC over Android ...
This typically happens when you try to allocate big objects (e.g. bitmaps). ART. The ART (Android Runtime) was the replacement for the Dalvik...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I am also facing the same not able to identify the issue. It occurs in production.
We’ll provide either a workaround or will change the default behaviour in the next major version, thanks everyone for the reports!