Die Android-App stürzt beim Start im Debug-Modus ab

290

Wenn ich im Debug- Modus laufe, stürzt die App ab, aber wenn ich sie nur normal starte, funktioniert sie. Ich denke, das Problem tritt auf, wenn der Debugger angehängt ist.

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
Maxim Rabtsun
quelle
Ich weiß nicht, was passiert ist, aber jetzt arbeite ich daran. Magie!!!
Maxim Rabtsun
Ich bin auf das gleiche Problem gestoßen und es war komplett BS. Selbst ein Neustart des Emulators hat nicht geholfen. Nachdem ich eine Menge Code entfernt und dann in einem Block nach dem anderen gelesen hatte, kehrte ich zum ursprünglichen Code zurück und das Problem war behoben. Ich habe das Gefühl, dass das Klassenobjekt nur neu erstellt werden musste. Eine Kompilierung ist schief gelaufen. Ich vermute, ein Projekt "sauber" hätte es wahrscheinlich behoben.
Dakusan
Fast 3 Jahre später ist dieser Fehler immer noch vorhanden.
Attila Tanyi

Antworten:

321

Für mich ist es aufgetreten, wenn ich einen Haltepunkt in einer verschachtelten Funktion habe. In meinem Fall war es innerhalb Runnable.run() {}. Nicht sicher, ob es in anderen verschachtelten Funktionen passiert.

Beispiel:

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

Wenn sich in einer Zeile der Funktion run () ein Haltepunkt befindet, stürzt dieser mit dem Fehler ab A/art: art/runtime/jdwp/jdwp_event.cc:661] Check failed: Thread::Current() != GetDebugThread() (Thread::Current()=0x########, GetDebugThread()=0x########) Expected event thread.

Dieser Fehler tritt beim ersten Auftreten der Klasse auf, NICHT beim Erreichen des Haltepunkts. So kam es mir vor, als ich in eine Zeile trat new TouchEvent();, bevor der Code des TouchEvent ausgeführt wurde (vor dem Konstruktor).

Die Lösung besteht darin, den Haltepunkt zu entfernen (und an einer anderen Stelle zu platzieren).

Bearbeiten:

Ich habe vergessen zu erwähnen, dass es an API25 gebunden zu sein scheint, wurde aber auch für API26 und API27 gemeldet.

Bearbeiten:

Eine andere Lösung besteht darin, Instant Run zu deaktivieren. Bitte geben Sie @ toobsco42 die unten angegebene Gutschrift.

Dakusan
quelle
28
Dies wurde auf code.google.com gemeldet und ich arbeite daran, es dort zu beheben. code.google.com/p/android/issues/detail?id=227513
Dakusan
4
Ich habe SDK 23 und Build Tools 25.0.1 - das gleiche Problem. Das Entfernen der Haltepunkte behebt dies.
Bonton255
2
Sie können den Haltepunkt auch entfernen, auf Debuggen klicken und ihn nach dem Ausführen der App wieder an der gewünschten Stelle hinzufügen. Funktioniert dann einwandfrei. Denken Sie daran, es vor dem Neustart zu entfernen.
Kometenfisch
3
Ich habe die Emulatoren gewechselt und das Problem ist verschwunden - ich habe wieder zum ursprünglichen Emulator gewechselt und das Problem ist zurückgekommen. Sobald das Problem auftritt, besteht die einzige Möglichkeit, es zu beheben (neben dem Löschen aller Haltepunkte - nein danke), darin, Instant Run zu deaktivieren. Durch erneutes Aktivieren von Instant Run auf dem Problememulator wird das Problem zurückgebracht.
Andy
11
Das Problem ist eine Mischung aus Haltepunkten in anderen Threads unter 7.1.1 mit sofortiger Ausführung. Ändern Sie also eine der oben genannten 3 und es wird nicht mehr abstürzen.
Warpzit
187

In meinem Fall musste ich Instant Run deaktivieren. Es scheint, dass Instant Run alle möglichen Nebenwirkungen hat und dies kann eine davon sein.

toobsco42
quelle
47
Beachten Sie, dass sich in Android Studio unter Datei -> Einstellungen -> Erstellen, Ausführen, Bereitstellen -> Sofortige Ausführung befindet.
Shortstuffsushi
Es war auch mein Fall! Danke: D
francisco_ssb
9
Das war eine Stunde meines Lebens, die ich nie wieder sehen werde
Gary Bak
3
Wenn ich auf mehreren Computern arbeite und Google ständig sofort wieder ausführt, muss ich damit ungefähr 4216% effizienter werden, wenn es endlich funktioniert, um meine verlorene Zeit aus der Ferne wiederzuerlangen.
Anthony
Vielen Dank. sollte als Antwort angekreuzt werden;) Diese hässliche Funktion gibt Ihnen fünf Cent und verschwendet Ihnen hundert Dollar :))
Amir Ziarati
50

Das Problem hängt mit Android Version 7.x zusammen. Ich habe alle Haltepunkte in verschachtelten Funktionen entfernt und es hat funktioniert, auch mit Android Version 6.0 getestet und es funktioniert ohne Probleme.

Laut der Antwort des Google-Entwicklerteams wurde dies am 01.12.2016 behoben und wird in der nächsten Version angewendet.

hcknl
quelle
habe alles Mögliche versucht, obiger Kommentar hat geholfen! Vielen Dank!
Stepan Maksymov
Es hat funktioniert, dies sollte als Antwort akzeptiert werden. Vielen Dank ! Sie können auch Instant Run als eine andere Lösung entfernen
Özer Özcan
Es wäre schön, wenn ein Link angehängt wäre, um dies zu unterstützen;) "Laut der Antwort des Google-Entwicklerteams wurde dieser am 01.12.2016 behoben und wird in der nächsten Version angewendet."
jabu.hlong
Wahrscheinlich war eine E-Mail-Antwort, die heute noch diesen Fehler bekam und Haltepunkte entfernen musste
Jim Factor
Android 7.1.1 ist immer noch die Version von Android, die auf dem Pixelbook ausgeführt wird. Ich bekomme das die ganze Zeit in Android Studio auf dem Pixelbook zu entwickeln!
Jeff Lockhart
21

Ich habe alle Haltepunkte entfernt und es hat funktioniert, getestet mit Emulator Pixel API 25.

So entfernen Sie alle Haltepunkte:

  • Gehen Sie zur Debugger-Option.

  • Klicken Sie auf das rote Symbol unten, um das Debuggen zu beenden.

  • Dort sehen Sie ein Fenster, in dem Sie alle Haltepunkte entfernen können.

Weitere Informationen finden Sie in diesem Beitrag: https://stackoverflow.com/a/42478994/5749462

Creonilso Rodrigues
quelle
16

Dies ist auf ein Problem mit Debugpunkten zurückzuführen. Entfernen Sie alle Debug-Punkte und dann sollte es funktionieren.

Flamme3
quelle
3
Mit der Tastenkombination STRG + UMSCHALT + F8 können Sie alle Haltepunkte einfach entfernen.
Brunoramonalmeida
Diese Verknüpfung funktioniert nicht immer, abhängig von Ihren Betriebssystem- und Tastatureinstellungen
Flamme3
8

Es ist wirklich komisch, ich habe Instant Run deaktiviert und das Problem hat sich von selbst gelöst.

mbpakalin
quelle
Ja, die sofortige Ausführung auf Geräten unter Android 7.0 kann dieses Problem leicht verursachen
egorikem
4

Mein Problem war, dass ich bei der Importanweisung einen Haltepunkt hatte

egorikem
quelle
Und wie zum dritten Mal darauf
gestoßen
3

Geben Sie hier die Bildbeschreibung ein

Verwenden Sie im Fenster 5: Debuggen die Schaltfläche "Haltepunkte anzeigen".

Geben Sie hier die Bildbeschreibung ein

Deaktivieren Sie alle

Geben Sie hier die Bildbeschreibung ein

Nicoolasens
quelle
1

Die einfachste Lösung besteht darin , ein anderes Gerät oder einen anderen Emulator zu finden (dank AVD Manager haben wir die Wahl), das ohne Problemumgehungen als Charme fungiert

yoAlex5
quelle
1

Meine App stürzte auch nur im Debug-Modus ab. In der Version 3.5 wurde "Instant Run" durch "Apply Changes" ersetzt, sodass ich es nicht deaktivieren konnte. Meine Lösung bestand darin, die App normal zu starten (mit dem grünen Pfeil), direkt nach der Stelle zu navigieren, an der sie abgestürzt war, und dann den Debugger daran anzuhängen:
Geben Sie hier die Bildbeschreibung ein

TDG
quelle
0

Das Entfernen des Haltepunkts aus Runable.run () hat das Problem für mich behoben. Ich konnte Haltepunkte zur Laufzeit in Runable.run () verwenden. Aber nicht zur Kompilierungszeit

Ankush
quelle
0

Ich bin auf dasselbe Problem gestoßen, aber mein Haltepunkt war die erste Zeile in der verschachtelten Funktion. Wie kann ich sie an eine andere Stelle verschieben?

Ich habe eine temporäre private Methode erstellt und als erstes in der Funktion einen Aufruf dieser Methode vorgenommen. Anschließend habe ich den Haltepunkt in dieser Methode festgelegt.

Als ich mit dem Debuggen fertig war, entfernte ich die Methode und ihren Aufruf.

Bartonstanley
quelle
0

Es ist ein langer Weg, aber für mich, wenn ich eine Importanweisung habe, die nicht verwendet wird, und dieser Import Code enthält, der Netzwerkaufrufe ausführt, ist er für mich abgestürzt, aber beim Entfernen konnte der Code normal debuggen.

reidisaki
quelle
0

Absturz nur beim Starten mit dem Debugger. Neustart von Android Studio 2.3.2 ... stürzte immer wieder ab. Läuft gut im Run-Modus. Ich habe direkt nach onCreate eine Log.d () eingefügt ... und das Problem wurde behoben! Stelle dir das vor!

IrvineCAGuy
quelle
0

Alle Debugpunkte in meiner Anwendung löschen funktioniert einwandfrei. Sie können Strg + Umschalt + F6 verwenden, um alle Debugpunkte zu entfernen

Arun Prajapati
quelle