在调试模式下启动时，Android应用程序崩溃

本文翻译自：Android app crashes when launched in debug mode

When I run in debug mode the app crashes, but when I just run it normally it works. 在调试模式下运行时，应用程序崩溃，但是在正常运行时，它可以正常运行。 I think the problem happens when the debugger is attached. 我认为问题是在连接调试器时发生的。

Log: 日志：

A/art: art/runtime/jdwp/jdwp_event.cc:661] Check failed: Thread::Current() != GetDebugThread() (Thread::Current()=0x7f44a18400, GetDebugThread()=0x7f44a18400) Expected event thread
A/art: art/runtime/runtime.cc:422] Runtime aborting...
A/art: art/runtime/runtime.cc:422] Aborting thread:
A/art: art/runtime/runtime.cc:422] "JDWP" prio=5 tid=4 WaitingForDebuggerSend
A/art: art/runtime/runtime.cc:422]   | group="" sCount=0 dsCount=0 obj=0x12c60280 self=0x7f44a18400
A/art: art/runtime/runtime.cc:422]   | sysTid=24137 nice=0 cgrp=default sched=0/0 handle=0x7f4b904450
A/art: art/runtime/runtime.cc:422]   | state=R schedstat=( 132066712 16401043 106 ) utm=9 stm=2 core=3 HZ=100
A/art: art/runtime/runtime.cc:422]   | stack=0x7f4b80a000-0x7f4b80c000 stackSize=1005KB
A/art: art/runtime/runtime.cc:422]   | held mutexes= "abort lock"
A/art: art/runtime/runtime.cc:422]   native: #00 pc 000000000047e2cc  /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+220)
A/art: art/runtime/runtime.cc:422]   native: #01 pc 000000000047e2c8  /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiP12BacktraceMapPKcPNS_9ArtMethodEPv+216)
A/art: art/runtime/runtime.cc:422]   native: #02 pc 0000000000452434  /system/lib64/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+480)
A/art: art/runtime/runtime.cc:422]   native: #03 pc 00000000004403ac  /system/lib64/libart.so (_ZNK3art10AbortState10DumpThreadERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEPNS_6ThreadE+56)
A/art: art/runtime/runtime.cc:422]   native: #04 pc 0000000000440228  /system/lib64/libart.so (_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+668)
A/art: art/runtime/runtime.cc:422]   native: #05 pc 0000000000433bfc  /system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+148)
A/art: art/runtime/runtime.cc:422]   native: #06 pc 00000000000e597c  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+1592)
A/art: art/runtime/runtime.cc:422]   native: #07 pc 00000000002f8458  /system/lib64/libart.so (_ZN3art4JDWP9JdwpState24AcquireJdwpTokenForEventEm+624)
A/art: art/runtime/runtime.cc:422]   native: #08 pc 00000000002f7b1c  /system/lib64/libart.so (_ZN3art4JDWP9JdwpState29SendRequestAndPossiblySuspendEPNS0_9ExpandBufENS0_17JdwpSuspendPolicyEm+248)
A/art: art/runtime/runtime.cc:422]   native: #09 pc 00000000002fcb08  /system/lib64/libart.so (_ZN3art4JDWP9JdwpState16PostClassPrepareEPNS_6mirror5ClassE+1380)
A/art: art/runtime/runtime.cc:422]   native: #10 pc 0000000000124a9c  /system/lib64/libart.so (_ZN3art11ClassLinker11DefineClassEPNS_6ThreadEPKcmNS_6HandleINS_6mirror11ClassLoaderEEERKNS_7DexFileERKNS9_8ClassDefE+804)
A/art: art/runtime/runtime.cc:422]   native: #11 pc 0000000000381d04  /system/lib64/libart.so (_ZN3artL25DexFile_defineClassNativeEP7_JNIEnvP7_jclassP8_jstringP8_jobjectS7_S7_+344)
A/art: art/runtime/runtime.cc:422]   native: #12 pc 00000000001dd40c  /system/framework/arm64/boot-core-libart.oat (???)
A/art: art/runtime/runtime.cc:422]   at dalvik.system.DexFile.defineClassNative(Native method)
A/art: art/runtime/runtime.cc:422]   at dalvik.system.DexFile.defineClass(DexFile.java:296)
A/art: art/runtime/runtime.cc:422]   at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:289)
A/art: art/runtime/runtime.cc:422]   at dalvik.system.DexPathList.findClass(DexPathList.java:418)
A/art: art/runtime/runtime.cc:422]   at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:54)
A/art: art/runtime/runtime.cc:422]   at com.android.tools.fd.runtime.IncrementalClassLoader$DelegateClassLoader.findClass(IncrementalClassLoader.java:90)
A/art: art/runtime/runtime.cc:422]   at com.android.tools.fd.runtime.IncrementalClassLoader.findClass(IncrementalClassLoader.java:62)
A/art: art/runtime/runtime.cc:422]   at java.lang.ClassLoader.loadClass(ClassLoader.java:380)
A/art: art/runtime/runtime.cc:422]   at java.lang.ClassLoader.loadClass(ClassLoader.java:367)
A/art: art/runtime/runtime.cc:422]   at java.lang.ClassLoader.loadClass(ClassLoader.java:367)
A/art: art/runtime/runtime.cc:422]   at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
A/art: art/runtime/runtime.cc:422] Dumping all threads without appropriate locks held: thread list lock mutator lock

---

#1楼

参考：https://stackoom.com/question/2KqNZ/在调试模式下启动时-Android应用程序崩溃

---

#2楼

For me, it occurred when I have a breakpoint in a nested function. 对我来说，它是在嵌套函数中有断点时发生的。 In my case, it was within Runnable.run() {} . 就我而言，它在Runnable.run() {} 。 Not sure if it happens in other nested functions. 不知道它是否在其他嵌套函数中发生。

Example: 例：

public class TouchEvent {
    public boolean HandleEvent(MotionEvent Event) {
        new Runnable() { @Override public void run() {
            int i=5;
            i++;
        }};
    }
}

If there is a breakpoint on any line inside the run() func, it crashes with the error A/art: art/runtime/jdwp/jdwp_event.cc:661] Check failed: Thread::Current() != GetDebugThread() (Thread::Current()=0x########, GetDebugThread()=0x########) Expected event thread . 如果run（）函数内部的任何行上都有断点，它将崩溃并显示错误A/art: art/runtime/jdwp/jdwp_event.cc:661] Check failed: Thread::Current() != GetDebugThread() (Thread::Current()=0x########, GetDebugThread()=0x########) Expected event thread 。

This error occurs the first time the class is encountered, NOT when the breakpoint is hit. 第一次遇到该类时发生此错误，而不是在遇到断点时发生。 So it occurred for me when I stepped into a line that had new TouchEvent(); 因此，当我进入具有new TouchEvent();的行时，这种情况就发生了new TouchEvent(); , before any of the TouchEvent's code was run (before the constructor). ，在运行任何TouchEvent的代码之前（在构造方法之前）。

The solution is to remove the break point (and put it elsewhere). 解决方案是删除断点（并将其放置在其他位置）。

Edit: 编辑：

Forgot to mention, it seems to be tied to API25, but has been reported for API26 and API27 too. 忘了提了，它似乎与API25有关，但也有关于API26和API27的报道。

Edit: 编辑：

Another solution is to disabled Instant Run , but please give @toobsco42 credit for that below. 另一个解决方案是禁用Instant Run ，但请在下面提供@ toobsco42积分。

---

#3楼

Problem is related with Android version 7.x, i removed all the breakpoints in nested functions and it worked, tested with Android version 6.0 too, and it is working without problem. 问题与Android版本7.x有关，我删除了嵌套函数中的所有断点，并且它可以正常工作，并且也已在Android版本6.0中进行了测试，并且工作正常。

According to google developers team response, it was fixed on 12/1/2016 and will be applied in next release. 根据Google开发人员小组的回复，该问题已于2016年1月1日修复，并将在下一个版本中应用。

---

#4楼

In my case i had to disable Instant Run. 就我而言，我必须禁用即时运行。 It seems like Instant Run has all sorts of side effects and this can be one of them. 看来Instant Run有各种各样的副作用，这可能是其中之一。

---

#5楼

Removing breakpoint from Runable.run() solved the issue for me. 从Runable.run（）删除断点为我解决了这个问题。 I was able to use breakpoints at runtime inside Runable.run(). 我可以在运行时在Runable.run（）中使用断点。 But not at compile time 但不是在编译时

---

#6楼

它真的很奇怪，我禁用了Instant Run，问题得以解决。