Usterka aplikacji na Androida po uruchomieniu w trybie debugowania

Question

Po uruchomieniu trybu debugowania aplikacja ulega awarii, ale po uruchomieniu normalnie działa. Myślę, że problem występuje, gdy dołączony jest debugger.

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 

Answer 1

Dla mnie to nastąpiło, gdy mam przerwania w zagnieżdżonej funkcji. W moim przypadku było to w Runnable.run() {}. Nie jestem pewien, czy dzieje się to w innych zagnieżdżonych funkcjach.

przykład:

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

Jeśli jest przerwania na dowolnej pozycji wewnątrz run() func, to zawiesza się błędem A/art: art/runtime/jdwp/jdwp_event.cc:661] Check failed: Thread::Current() != GetDebugThread() (Thread::Current()=0x########, GetDebugThread()=0x########) Expected event thread.

Ten błąd pojawia się przy pierwszym napotkaniu klasy, a NIE po trafieniu punktu przerwania. Tak się stało, gdy wkroczyłem w linię, która miała new TouchEvent();, zanim którykolwiek z kodów TouchEvent został uruchomiony (przed konstruktorem).

Rozwiązaniem jest usunięcie punktu przerwania (i umieszczenie go w innym miejscu).

Edit:

Zapomniałem wspomnieć, wydaje się być związany z API25

Answer 2

problem jest związany z systemem Android w wersji 7.x, usunąłem wszystkie punkty przerwania w funkcji zagnieżdżonych i to działało, testowane z systemem Android w wersji 6.0 i działa bez problemu.

Zgodnie z odpowiedzią zespołu programistycznego google została ona rozwiązana w dniu 12/1/2016 i zostanie zastosowana w następnym wydaniu.

Answer 3

W moim przypadku musiałem wyłączyć Instant Run. Wygląda na to, że Instant Run ma wiele różnych efektów ubocznych, a to może być jedna z nich.

Answer 4

Usunięcie punktu przerwania z Runable.run() rozwiązało problem. Byłem w stanie używać punktów przerwania w czasie wykonywania w Runable.run(). Ale nie w czasie kompilacji

Answer 5

To naprawdę dziwne, wyłączone Instant Run i problem sam się rozwiązał.

Answer 6

Wystąpił ten sam problem, ale mój punkt przerwania był pierwszym wierszem w funkcji zagnieżdżonej, więc jak przenieść go gdzie indziej?

Utworzono tymczasową metodę prywatną i wywołałem wywołanie tej metody pierwszą rzeczą w funkcji, a następnie ustawiłem punkt przerwania w tej metodzie.

Po zakończeniu debugowania usunąłem metodę i jej wywołanie.

Answer 7

Mój problem było to, że miałem przerwania w instrukcji import

Answer 8

usunąłem wszystkie punkty przerwania i to działało, przetestowane z Emulator Pixel API 25.

Aby usunąć wszystkie punkty przerwania:

• Przejdź do opcji Debugger.

• Kliknij czerwoną ikonę poniżej, aby zatrzymać debugowanie.

• Zobaczysz okno, w którym możesz usunąć wszystkie punkty przerwania.

Zobacz więcej w tym poście: https://stackoverflow.com/a/42478994/5749462

Answer 9

jest to długi strzał, ale dla mnie, kiedy mam oświadczenie import, który nie jest używany, a import ma kod, który działa połączeń sieciowych, rozbił się dla mnie, ale podczas usuwania kod był w stanie normalnie debugować.

Answer 10

Uruchamianie awarii tylko podczas uruchamiania z debugerem. Restarted Android Studio 2.3.2 ... ciągle się zawiesza. Działa dobrze w trybie Run. Wstawiłem Log.d() zaraz po onCreate ... i to wyjaśniło problem! Domyśl!

Answer 11

Jest to spowodowane pewnym problemem z punktami debugowania. Usuń wszystkie punkty debugowania, a następnie powinno działać.