What is causing this crash with output "Check failed: threadId != 0u"?

Question

I'm getting the below output in my code randomly (not related to any action that I can identify) when my application crashes. Can some one help me decipher what this logcat output means?

I've truncated a large portion of the text that seems to list out the various threads along with their States (waiting, timed-waiting, blocked, etc. . ) along with the stacktrace for the method calls on that thread.

07-31 14:39:40.455 942-947/com.salesrabbit.android.sales.universal A/art: art/runtime/jdwp/jdwp_event.cc:681] Check failed: threadId != 0u (threadId=0, 0u=0) 
07-31 14:39:43.283 942-947/com.salesrabbit.android.sales.universal A/art: art/runtime/runtime.cc:422] Runtime aborting...
    art/runtime/runtime.cc:422] Aborting thread:
    art/runtime/runtime.cc:422] "Jit thread pool worker thread 0" prio=5 tid=2 WaitingForDebuggerSend (still starting up)
    art/runtime/runtime.cc:422]   | group="" sCount=0 dsCount=0 obj=0x0 self=0xa8617000
    art/runtime/runtime.cc:422]   | sysTid=947 nice=9 cgrp=default sched=0/0 handle=0xaf2a3920
    art/runtime/runtime.cc:422]   | state=R schedstat=( 8833095069 6087499776 14348 ) utm=557 stm=325 core=2 HZ=100
    art/runtime/runtime.cc:422]   | stack=0xaf1a5000-0xaf1a7000 stackSize=1022KB
    art/runtime/runtime.cc:422]   | held mutexes= "abort lock"
    art/runtime/runtime.cc:422]   native: #00 pc 00351069  /system/lib/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+128)
    art/runtime/runtime.cc:422]   native: #01 pc 00331729  /system/lib/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+304)
    art/runtime/runtime.cc:422]   native: #02 pc 003247a1  /system/lib/libart.so (_ZNK3art10AbortState10DumpThreadERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEPNS_6ThreadE+24)
    art/runtime/runtime.cc:422]   native: #03 pc 00324629  /system/lib/libart.so (_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+424)
    art/runtime/runtime.cc:422]   native: #04 pc 0031b351  /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+92)
    art/runtime/runtime.cc:422]   native: #05 pc 000b526b  /system/lib/libart.so (_ZN3art10LogMessageD2Ev+1134)
    art/runtime/runtime.cc:422]   native: #06 pc 00240305  /system/lib/libart.so (_ZN3art4JDWP9JdwpState19SetWaitForJdwpTokenEy+708)
    art/runtime/runtime.cc:422]   native: #07 pc 0023fb51  /system/lib/libart.so (_ZN3art4JDWP9JdwpState24AcquireJdwpTokenForEventEy+76)
    art/runtime/runtime.cc:422]   native: #08 pc 0023f5e1  /system/lib/libart.so (_ZN3art4JDWP9JdwpState29SendRequestAndPossiblySuspendEPNS0_9ExpandBufENS0_17JdwpSuspendPolicyEy+180)
    art/runtime/runtime.cc:422]   native: #09 pc 0024301b  /system/lib/libart.so (_ZN3art4JDWP9JdwpState16PostClassPrepareEPNS_6mirror5ClassE+914)
    art/runtime/runtime.cc:422]   native: #10 pc 000e4db5  /system/lib/libart.so (_ZN3art11ClassLinker11DefineClassEPNS_6ThreadEPKcjNS_6HandleINS_6mirror11ClassLoaderEEERKNS_7DexFileERKNS9_8ClassDefE+560)
    art/runtime/runtime.cc:422]   native: #11 pc 000e4a15  /system/lib/libart.so (_ZN3art11ClassLinker26FindClassInPathClassLoaderERNS_33ScopedObjectAccessAlreadyRunnableEPNS_6ThreadEPKcjNS_6HandleINS_6mirror11ClassLoaderEEEPPNS8_5ClassE+1016)
    art/runtime/runtime.cc:422]   native: #12 pc 000e55ef  /system/lib/libart.so (_ZN3art11ClassLinker9FindClassEPNS_6ThreadEPKcNS_6HandleINS_6mirror11ClassLoaderEEE+658)
    art/runtime/runtime.cc:422]   native: #13 pc 000d2a3d  /system/lib/libart.so (_ZN3art11ClassLinker11ResolveTypeERKNS_7DexFileEtNS_6HandleINS_6mirror8DexCacheEEENS4_INS5_11ClassLoaderEEE+132)
    art/runtime/runtime.cc:422]   native: #14 pc 001354bd  /system/lib/libart-compiler.so (_ZNK3art19HInstructionBuilder25IsOutermostCompilingClassEt+528)
    art/runtime/runtime.cc:422]   native: #15 pc 00134e5b  /system/lib/libart-compiler.so (_ZN3art19HInstructionBuilder16BuildNewInstanceEtj+626)
    art/runtime/runtime.cc:422]   native: #16 pc 0012ffe7  /system/lib/libart-compiler.so (_ZN3art19HInstructionBuilder21ProcessDexInstructionERKNS_11InstructionEj+3522)
    art/runtime/runtime.cc:422]   native: #17 pc 0012ece9  /system/lib/libart-compiler.so (_ZN3art19HInstructionBuilder5BuildEv+1176)
    art/runtime/runtime.cc:422]   native: #18 pc 00113b79  /system/lib/libart-compiler.so (_ZN3art13HGraphBuilder10BuildGraphEv+84)
    art/runtime/runtime.cc:422]   native: #19 pc 00157ea9  /system/lib/libart-compiler.so (_ZNK3art18OptimizingCompiler10TryCompileEPNS_14ArenaAllocatorEPNS_19CodeVectorAllocatorEPKNS_7DexFile8CodeItemEjNS_10InvokeTypeEtjP8_jobjectRKS5_NS_6HandleINS_6mirror8DexCacheEEEPNS_9ArtMethodEb+2452)
    art/runtime/runtime.cc:422]   native: #20 pc 00159ae3  /system/lib/libart-compiler.so (_ZN3art18OptimizingCompiler10JitCompileEPNS_6ThreadEPNS_3jit12JitCodeCacheEPNS_9ArtMethodEb+330)
    art/runtime/runtime.cc:422]   native: #21 pc 00108e1f  /system/lib/libart-compiler.so (_ZN3art3jit11JitCompiler13CompileMethodEPNS_6ThreadEPNS_9ArtMethodEb+194)
    art/runtime/runtime.cc:422]   native: #22 pc 00250473  /system/lib/libart.so (_ZN3art3jit3Jit13CompileMethodEPNS_9ArtMethodEPNS_6ThreadEb+318)
    art/runtime/runtime.cc:422]   native: #23 pc 00251b97  /system/lib/libart.so (_ZN3art3jit14JitCompileTask3RunEPNS_6ThreadE+430)
    art/runtime/runtime.cc:422]   native: #24 pc 003445a1  /system/lib/libart.so (_ZN3art16ThreadPoolWorker3RunEv+44)
    art/runtime/runtime.cc:422]   native: #25 pc 003440d9  /system/lib/libart.so (_ZN3art16ThreadPoolWorker8CallbackEPv+64)
    art/runtime/runtime.cc:422]   native: #26 pc 00047093  /system/lib/libc.so (_ZL15__pthread_startPv+22)
    art/runtime/runtime.cc:422]   native: #27 pc 00019bdd  /system/lib/libc.so (__start_thread+6)
    art/runtime/runtime.cc:422]   (no managed stack frames)
    art/runtime/runtime.cc:422] Dumping all threads without appropriate locks held: thread list lock mutator lock
    art/runtime/runtime.cc:422] All threads:
07-31 14:39:43.285 942-947/com.salesrabbit.android.sales.universal A/art: art/runtime/runtime.cc:422] DALVIK THREADS (470):
    art/runtime/runtime.cc:422] "Jit thread pool worker thread 0" prio=5 tid=2 Runnable (still starting up)
    art/runtime/runtime.cc:422]   | group="" sCount=0 dsCount=0 obj=0x0 self=0xa8617000
    art/runtime/runtime.cc:422]   | sysTid=947 nice=9 cgrp=default sched=0/0 handle=0xaf2a3920
    art/runtime/runtime.cc:422]   | state=R schedstat=( 9523364645 6173422596 15193 ) utm=559 stm=392 core=0 HZ=100
    art/runtime/runtime.cc:422]   | stack=0xaf1a5000-0xaf1a7000 stackSize=1022KB
    art/runtime/runtime.cc:422]   | held mutexes= "abort lock" "mutator lock"(shared held)
    art/runtime/runtime.cc:422]   native: #00 pc 00351069  /system/lib/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+128)
    art/runtime/runtime.cc:422]   native: #01 pc 00331729  /system/lib/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+304)
    art/runtime/runtime.cc:422]   native: #02 pc 0034382f  /system/lib/libart.so (_ZN3art14DumpCheckpoint3RunEPNS_6T

I've truncated a bunch of other threads:

     --------- beginning of crash
07-31 14:39:43.630 942-947/com.salesrabbit.android.sales.universal A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 947 (Jit thread pool)

EDIT 1

I updated my android studio from 3.0.1 to 3.1.3 (as well as gradle) yesterday and the issue went away until today after lunch it randomly came back. I tried invalidating the cache and restating android studio but it did not have any affect. I still get this crash about 2 minutes after building/installing the app on a test device. It happens on all of our test devices.

EDIT 2

I just discovered that if I turned off all my breakpoints the crash goes away. If I put the break point back the crash come back. This is very annoying!

In the code below, if I put a break point on db.endTransaction(), the app crashes. Why? How can I fix this?

return Single.just(page)
    .map {
        val db: Database = daoSession.database
        db.beginTransaction()
        . . . .
        db.setTransactionSuccessful()
        db.endTransaction()
        return@map page
    }
    .map {
        geoCodeAsNeeded(page.addressToGeoCode)
        return@map page
    }
    .map {
        return someMethod()
    }
    .subscribeOn(Schedulers.io())

I ran into the same issue. I found out I had a large number of old unused breakpoints hanging around the application. Clearing all these and adding just the right breakpoint I needed for my current debug session did the trick. Your EDIT2, was all I needed to get on track. Thanks! :) — Schm1, May 11 '21 at 11:47

ygngy · Answer 1 · 2018-07-28T22:19:58.950

3

As this line from stack trace says:

Fatal signal 6 (SIGABRT), code -6 in tid 8509 (Jit thread pool)

your error is SIGABRT signal.

1) Do not block the UI thread, this can cause a SIGABRT as the OS will kill a non-responsive app.

2) Make sure that in your OnDestroy within your Activity you are cleaning up after yourself. i.e. Removing all your Listeners/Events and then calling the Base.OnDestory.

3) An external (i.e. BluetoothLeService) service calling back into your app with listeners that now null/nil will cause hangs and thus a SIGABRT, see #2

more answers: What is fatal signal 6 in android logcat

if you could not find error location you have to find it by changing parts of your code to comment to see if problem solves.

edited Jul 28 '18 at 22:19

answered Jul 27 '18 at 21:02

ygngy

3,630
2
18
29

Insetad of `onDestroy` you should remove your listners/events from `onStop` as `onDestroy` is not `guaranteed` and register them back in `onResume` – prashant17 Jul 28 '18 at 16:55
@prashant17 you made two mistakes first always use pairs if you register listener in Resume you should unregister it in Pause (or use Start/Stop or use Create/Destroy) using your way an Activity may go to pause and resume multiple times without going to stop thus you register listener multiple times but newer unregister it until stop. second mistake is that when `onDestroy` is not called all of your process is terminated and there is no need to unregister listener. also `onStop` may not get called as `onDestroy` Though less likely. – ygngy Jul 28 '18 at 22:08
@WIZARD, I'm using Rx java and all my new code is running on the io thread (Schedulers.io()) The stack trace also lists the offending thread as id=0, that thread is all native calls. Do you have any idea what is spawning that thread. – Dan Anderson Jul 30 '18 at 14:47
@DanAnderson io thread is using a pool of threads "Jit thread pool" has many threads for worker threads to work in parallel here starting tid (thread id) is 2 and the thread that made exception has tid (thread id) 8509 – ygngy Jul 30 '18 at 18:55
@WIZARD I have updated my question with more information. – Dan Anderson Jul 31 '18 at 21:02
@DanAnderson when you run app with break point exception is thrown or when you DEBUG app with break point and when app is stopped at that break point the exception is thrown? – ygngy Aug 01 '18 at 17:35
@DanAnderson make sure that db transaction is NOT done on main app thread – ygngy Aug 01 '18 at 17:39
@WIZARD There is no crash if I run the app with a break point there. If I debug with the break point then it has to crash. It only crashes after the break point is hit. Correct it is not happening on the Main thread. – Dan Anderson Aug 01 '18 at 19:54
@DanAnderson test this add `SystemClock.sleep()` or `Thread.sleep()` (with a waiting time greater than the time you see exception) instead of break point and in place of break point (before its place and remove break point). then run your app (NOT debug) if there is no crash you can be sure there is no problem in your app and problem is in debuger.also at end do not forget to remove that sleep code. – ygngy Aug 01 '18 at 22:03

score -1 · Answer 2 · answered Nov 22 '21 at 07:29

-1

Just turn off your windows defender. Turn off all switches of defender.

answered Nov 22 '21 at 07:29

恩庭黄

1
1

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Nov 22 '21 at 08:27

What is causing this crash with output "Check failed: threadId != 0u"?

2 Answers2