Fehler bei der automatischen ART-Speicherbereinigung beheben

Auf dieser Seite wird beschrieben, wie Sie Fehler in der automatischen Speicherbereinigung von Android Runtime (ART) beheben können (GC) Richtigkeit und Leistungsprobleme. Es wird erläutert, wie die GC-Überprüfung verwendet wird. Optionen, Lösungen für Fehler bei der GC-Überprüfung identifizieren und Leistungsprobleme bei GC beheben.

Informationen zur Arbeit mit ART finden Sie auf den Seiten von ART und Dalvik und dem Dalvik Executable-Format. Weitere Informationen zum Überprüfen des App-Verhaltens findest du unter Wird verifiziert App-Verhalten in der Android-Laufzeit (ART)

ART GC-Übersicht

ART hat mehrere unterschiedliche GC-Tarife, die aus unterschiedlichen automatischen Speichervorgängen bestehen. Sammler. Ab Android 8 (Oreo) ist der Standardtarif „Gleichzeitiges Kopieren“. Der andere GC-Plan ist Concurrent Mark Sweep (CMS).

Einige der Hauptmerkmale der gleichzeitigen Kopierfunktion:

• CC ermöglicht die Verwendung einer Bump-Pointer-Zuordnung namens RegionTLAB. Weist einen Thread-lokalen Zuweisungszwischenspeicher (TLAB) für jeden Anwendungsthread, der dann Objekte aus seinem TLAB zuweisen kann indem sie die „Top“- Zeiger ohne Synchronisierung.
• CC führt eine Heap-Defragmentierung durch, indem Objekte gleichzeitig kopiert werden, ohne App-Threads zu pausieren. Dies wird mithilfe einer Lesebarriere erreicht, die Referenzlesevorgänge aus dem ohne Hilfe des App-Entwicklers.
• Bei GC gibt es nur eine kurze Pause, die in Bezug auf die Heap-Größe konstant ist.
• CC wird unter Android 10 und höher zu einer Generation des Google Cloud-Speichers. Es ermöglicht die Erfassung junge Objekte, die oft relativ schnell und mit wenig Aufwand nicht erreichbar sind. Das hilft, indem der GC-Durchsatz erhöht und die Notwendigkeit einer Voll-Heap-GC erheblich verzögert wird.

Das andere GC, das ART weiterhin unterstützt, ist CMS. Dieses GC unterstützt auch die Verdichtung, jedoch nicht gleichzeitig. Die Verdichtung wird vermieden, in den Hintergrund. Zu diesem Zeitpunkt werden die App-Threads für die Verdichtung angehalten. Die Komprimierung ist auch erforderlich, wenn eine Objektzuweisung aufgrund von Fragmentierung fehlschlägt. In dieser wenn die App möglicherweise für einige Zeit nicht mehr reagiert.

Da CMS selten kompakt wird und kostenlose Objekte daher möglicherweise nicht zusammenhängend sind, wird ein kostenlosen Listen-basierten Verteiler namens RosAlloc. Die Zuweisungskosten sind höher als an RegionTLAB. Aufgrund der internen Fragmentierung ist schließlich die Arbeitsspeichernutzung für den Java-Heap für CMS höher sein kann als CC.

GC-Überprüfung und Leistungsoptionen

Typ der Speicherbereinigung ändern

OEMs können den GC-Typ ändern. Der Änderungsprozess das Festlegen der Umgebungsvariable ART_USE_READ_BARRIER bei der Build-Erstellung. Der Standardwert ist „true“. Dadurch wird der CC-Collector aktiviert, wenn er die Lesebarriere verwendet. Für CMS muss explizit auf "false" gesetzt werden.

In Android 10 und höher wird der CC-Collector standardmäßig im Generationsmodus ausgeführt. Bis Generationsmodus deaktivieren, kann das -Xgc:nogenerational_cc-Befehlszeilenargument verwendet. Alternativ kann die Systemeigenschaft so festgelegt werden:

adb shell setprop dalvik.vm.gctype nogenerational_cc

Der CMS-Collector wird immer im Generationsmodus ausgeführt.

Heap prüfen

Die Heap-Überprüfung ist wahrscheinlich die nützlichste GC-Option für das Debugging GC-bezogene Fehler oder Heap-Beschädigungen. Die Aktivierung der Heap-Bestätigung führt zur automatischen Speicherbereinigung um die Richtigkeit des Heaps an einigen Punkten während des automatischen Speichers zu überprüfen Datensammlung. Für die Heap-Überprüfung stehen dieselben Optionen zur Verfügung wie die, bei denen GC-Typ ändern. Wenn diese Option aktiviert ist, werden die Stamm- und stellt sicher, dass erreichbare Objekte nur auf andere erreichbare Objekte verweisen. Speicherbereinigung Überprüfung wird aktiviert, indem die folgenden -Xgc-Werte übergeben werden:

• Wenn diese Option aktiviert ist, führt [no]preverify vor dem Start der automatischen Speicherbereinigung eine Heap-Überprüfung durch.
• Wenn diese Option aktiviert ist, führt [no]presweepingverify eine Heap-Überprüfung durch bevor Sie die automatische Speicherbereinigung starten.
• Wenn diese Option aktiviert ist, führt [no]postverify die Heap-Überprüfung nach dem GC beendet mit der Wischbewegung.
• [no]preverify_rosalloc, [no]postsweepingverify_rosalloc und [no]postverify_rosalloc sind zusätzliche GC-Optionen, die überprüft werden der internen Buchhaltung von RosAlloc. Daher gelten sie nur für dem CMS-Collector, der den RosAlloc-Allocator verwendet. Die wichtigsten Dinge, die überprüft werden, dass magische Werte den erwarteten Konstanten entsprechen und kostenlose Speicherblöcke in der Karte free_page_runs_ registriert.

Leistung

Es gibt zwei Haupttools zur Messung der GC-Leistung: GC-Timing dumps und Systrace an. Es gibt auch eine erweiterte Version von Systrace namens Perfetto. Die visuelle Messung von Leistungsproblemen bei GC die Verwendung von Systrace und Perfetto ist, das vorzeitige Beenden von App-Threads. Obwohl das ART GC mit der Zeit erheblich verbessert wurde, ist der Mutator wie eine übermäßige Zuweisungen, können trotzdem zu Leistungsproblemen führen.

Sammlungsstrategie

Die Speicherbereinigung für CC wird entweder durch eine junge oder eine vollständige Speicherbereinigung vollständig gesammelt. Idealerweise sollte der junge häufiger ausgeführt wird. Die automatische Speicherbereinigung führt bis zum Durchsatz (berechnet nach Byte) junge CC-Sammlungen durch freigegeben/Sekunde der GC-Dauer) des gerade abgeschlossenen Erfassungszyklus liegt unter dem durchschnittlichen Durchsatz von Full-Heap-CC-Sammlungen. In diesem Fall wird der Full-Heap-CC für den nächsten gleichzeitige automatische Speicherbereinigung anstelle von jungem CC. Nach Abschluss der vollständigen Heap-Erfassung ist der nächste GC wird wieder auf junge CC umgestellt. Ein entscheidender Faktor für diese Strategie ist, passt das Heap-Fußabdrucklimit nach Abschluss des Vorgangs nicht mehr an. Das führt dazu, dass junge Videokünstler und häufiger, bis der Durchsatz niedriger ist als der Voll-Heap-CC, wodurch am Ende der Heap vergrößert wird.

Mit SIGQUIT Informationen zur GC-Leistung abrufen

Um GC-Leistungszeiten für Apps zu erhalten, sende SIGQUIT an bereits ausgeführte Apps oder übergeben Sie -XX:DumpGCPerformanceOnShutdown auf dalvikvm setzen, wenn Sie ein Befehlszeilenprogramm starten. Wenn eine App des ANR-Anfragesignals (SIGQUIT) sendet er Informationen zu seinen Sperren Thread-Stacks und die GC-Leistung.

Verwenden Sie Folgendes, um GC-Timing-Dumps abzurufen:

adb shell kill -s QUIT PID

Dadurch wird eine Datei erstellt (mit Datum und Uhrzeit im Namen, z. B. anr_2020-07-13-19-23-39-817). in „/data/anr/“. Dieses Datei enthält einige ANR-Dumps und GC-Timings. Sie finden die GC-Zeitangaben durch Suchen nach Dumping kumulative Gc-times aus. Diese Zeitangaben einige Dinge, die Sie interessieren könnten, einschließlich der Histogramminformationen die Phasen und Pausen jedes GC-Typs. Die Pausen sind in der Regel wichtiger, um. Beispiel:

young concurrent copying paused:	Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms

Die durchschnittliche Pause betrug 1,83 ms, was ausreichend niedrig sein sollte, Das führt in den meisten Apps nicht zu fehlenden Frames und sollte kein Problem darstellen.

Auch die Zeit zum Aussetzen ist ein interessanter Bereich, wie lange es dauert, bis ein Thread einen Unterbrechungspunkt erreicht, nachdem die automatische Speicherbereinigung angefordert hat, hält er an. Diese Zeit ist in den GC-Pausen enthalten. Daher ist es hilfreich, Ermitteln, ob lange Pausen durch langsame Speicherbereinigung oder Thread verursacht werden wird langsam ausgesetzt. Hier ist ein Beispiel für einen normalen Zeitpunkt, auf einem Nexus 5:

suspend all histogram:	Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us

Es gibt auch andere Bereiche, die von Interesse sind, wie z. B. die Gesamtzeit und die automatische Speicherbereinigung. Durchsatz. Beispiele:

Total time spent in GC: 502.251ms
Mean GC size throughput: 92MB/s
Mean GC object throughput: 1.54702e+06 objects/s

Hier ist ein Beispiel, wie die GC-Timings einer bereits ausgeführten Anwendung ausgegeben werden:

adb shell kill -s QUIT PID
adb pull /data/anr/anr_2020-07-13-19-23-39-817

An diesem Punkt liegen die Zeiten für die automatische Speicherbereinigung innerhalb von anr_2020-07-13-19-23-39-817. Hier ist ein Ausgabebeispiel. aus Google Maps:

Start Dumping histograms for 2195 iterations for concurrent copying
MarkingPhase:   Sum: 258.127s 99% C.I. 58.854ms-352.575ms Avg: 117.651ms Max: 641.940ms
ScanCardsForSpace:      Sum: 85.966s 99% C.I. 15.121ms-112.080ms Avg: 39.164ms Max: 662.555ms
ScanImmuneSpaces:       Sum: 79.066s 99% C.I. 7.614ms-57.658ms Avg: 18.014ms Max: 546.276ms
ProcessMarkStack:       Sum: 49.308s 99% C.I. 6.439ms-81.640ms Avg: 22.464ms Max: 638.448ms
ClearFromSpace: Sum: 35.068s 99% C.I. 6.522ms-40.040ms Avg: 15.976ms Max: 633.665ms
SweepSystemWeaks:       Sum: 14.209s 99% C.I. 3.224ms-15.210ms Avg: 6.473ms Max: 201.738ms
CaptureThreadRootsForMarking:   Sum: 11.067s 99% C.I. 0.835ms-13.902ms Avg: 5.044ms Max: 25.565ms
VisitConcurrentRoots:   Sum: 8.588s 99% C.I. 1.260ms-8.547ms Avg: 1.956ms Max: 231.593ms
ProcessReferences:      Sum: 7.868s 99% C.I. 0.002ms-8.336ms Avg: 1.792ms Max: 17.376ms
EnqueueFinalizerReferences:     Sum: 3.976s 99% C.I. 0.691ms-8.005ms Avg: 1.811ms Max: 16.540ms
GrayAllDirtyImmuneObjects:      Sum: 3.721s 99% C.I. 0.622ms-6.702ms Avg: 1.695ms Max: 14.893ms
SweepLargeObjects:      Sum: 3.202s 99% C.I. 0.032ms-6.388ms Avg: 1.458ms Max: 549.851ms
FlipOtherThreads:       Sum: 2.265s 99% C.I. 0.487ms-3.702ms Avg: 1.031ms Max: 6.327ms
VisitNonThreadRoots:    Sum: 1.883s 99% C.I. 45us-3207.333us Avg: 429.210us Max: 27524us
InitializePhase:        Sum: 1.624s 99% C.I. 231.171us-2751.250us Avg: 740.220us Max: 6961us
ForwardSoftReferences:  Sum: 1.071s 99% C.I. 215.113us-2175.625us Avg: 488.362us Max: 7441us
ReclaimPhase:   Sum: 490.854ms 99% C.I. 32.029us-6373.807us Avg: 223.623us Max: 362851us
EmptyRBMarkBitStack:    Sum: 479.736ms 99% C.I. 11us-3202.500us Avg: 218.558us Max: 13652us
CopyingPhase:   Sum: 399.163ms 99% C.I. 24us-4602.500us Avg: 181.851us Max: 22865us
ThreadListFlip: Sum: 295.609ms 99% C.I. 15us-2134.999us Avg: 134.673us Max: 13578us
ResumeRunnableThreads:  Sum: 238.329ms 99% C.I. 5us-2351.250us Avg: 108.578us Max: 10539us
ResumeOtherThreads:     Sum: 207.915ms 99% C.I. 1.072us-3602.499us Avg: 94.722us Max: 14179us
RecordFree:     Sum: 188.009ms 99% C.I. 64us-312.812us Avg: 85.653us Max: 2709us
MarkZygoteLargeObjects: Sum: 133.301ms 99% C.I. 12us-734.999us Avg: 60.729us Max: 10169us
MarkStackAsLive:        Sum: 127.554ms 99% C.I. 13us-417.083us Avg: 58.111us Max: 1728us
FlipThreadRoots:        Sum: 126.119ms 99% C.I. 1.028us-3202.499us Avg: 57.457us Max: 11412us
SweepAllocSpace:        Sum: 117.761ms 99% C.I. 24us-400.624us Avg: 53.649us Max: 1541us
SwapBitmaps:    Sum: 56.301ms 99% C.I. 10us-125.312us Avg: 25.649us Max: 1475us
(Paused)GrayAllNewlyDirtyImmuneObjects: Sum: 33.047ms 99% C.I. 9us-49.931us Avg: 15.055us Max: 72us
(Paused)SetFromSpace:   Sum: 11.651ms 99% C.I. 2us-49.772us Avg: 5.307us Max: 71us
(Paused)FlipCallback:   Sum: 7.693ms 99% C.I. 2us-32us Avg: 3.504us Max: 32us
(Paused)ClearCards:     Sum: 6.371ms 99% C.I. 250ns-49753ns Avg: 207ns Max: 188000ns
Sweep:  Sum: 5.793ms 99% C.I. 1us-49.818us Avg: 2.639us Max: 93us
UnBindBitmaps:  Sum: 5.255ms 99% C.I. 1us-31us Avg: 2.394us Max: 31us
Done Dumping histograms
concurrent copying paused:      Sum: 315.249ms 99% C.I. 49us-1378.125us Avg: 143.621us Max: 7722us
concurrent copying freed-bytes: Avg: 34MB Max: 54MB Min: 2062KB
Freed-bytes histogram: 0:4,5120:5,10240:19,15360:69,20480:167,25600:364,30720:529,35840:405,40960:284,46080:311,51200:38
concurrent copying total time: 569.947s mean time: 259.657ms
concurrent copying freed: 1453160493 objects with total size 74GB
concurrent copying throughput: 2.54964e+06/s / 134MB/s  per cpu-time: 157655668/s / 150MB/s
Average major GC reclaim bytes ratio 0.486928 over 2195 GC cycles
Average major GC copied live bytes ratio 0.0894662 over 2199 major GCs
Cumulative bytes moved 6586367960
Cumulative objects moved 127490240
Peak regions allocated 376 (94MB) / 2048 (512MB)
Start Dumping histograms for 685 iterations for young concurrent copying
ScanCardsForSpace:      Sum: 26.288s 99% C.I. 8.617ms-77.759ms Avg: 38.377ms Max: 432.991ms
ProcessMarkStack:       Sum: 21.829s 99% C.I. 2.116ms-71.119ms Avg: 31.868ms Max: 98.679ms
ClearFromSpace: Sum: 19.420s 99% C.I. 5.480ms-50.293ms Avg: 28.351ms Max: 507.330ms
ScanImmuneSpaces:       Sum: 9.968s 99% C.I. 8.155ms-30.639ms Avg: 14.552ms Max: 46.676ms
SweepSystemWeaks:       Sum: 6.741s 99% C.I. 3.655ms-14.715ms Avg: 9.841ms Max: 22.142ms
GrayAllDirtyImmuneObjects:      Sum: 4.466s 99% C.I. 0.584ms-14.315ms Avg: 6.519ms Max: 24.355ms
FlipOtherThreads:       Sum: 3.672s 99% C.I. 0.631ms-16.630ms Avg: 5.361ms Max: 18.513ms
ProcessReferences:      Sum: 2.806s 99% C.I. 0.001ms-9.459ms Avg: 2.048ms Max: 11.951ms
EnqueueFinalizerReferences:     Sum: 1.857s 99% C.I. 0.424ms-8.609ms Avg: 2.711ms Max: 24.063ms
VisitConcurrentRoots:   Sum: 1.094s 99% C.I. 1.306ms-5.357ms Avg: 1.598ms Max: 6.831ms
SweepArray:     Sum: 711.032ms 99% C.I. 0.022ms-3.502ms Avg: 1.038ms Max: 7.307ms
InitializePhase:        Sum: 667.346ms 99% C.I. 303us-2643.749us Avg: 974.227us Max: 3199us
VisitNonThreadRoots:    Sum: 388.145ms 99% C.I. 103.911us-1385.833us Avg: 566.635us Max: 5374us
ThreadListFlip: Sum: 202.730ms 99% C.I. 18us-2414.999us Avg: 295.956us Max: 6780us
EmptyRBMarkBitStack:    Sum: 132.934ms 99% C.I. 8us-1757.499us Avg: 194.064us Max: 8495us
ResumeRunnableThreads:  Sum: 109.593ms 99% C.I. 6us-4719.999us Avg: 159.989us Max: 11106us
ResumeOtherThreads:     Sum: 86.733ms 99% C.I. 3us-4114.999us Avg: 126.617us Max: 19332us
ForwardSoftReferences:  Sum: 69.686ms 99% C.I. 14us-2014.999us Avg: 101.731us Max: 4723us
RecordFree:     Sum: 58.889ms 99% C.I. 0.500us-185.833us Avg: 42.984us Max: 769us
FlipThreadRoots:        Sum: 58.540ms 99% C.I. 1.034us-4314.999us Avg: 85.459us Max: 10224us
CopyingPhase:   Sum: 52.227ms 99% C.I. 26us-728.749us Avg: 76.243us Max: 2060us
ReclaimPhase:   Sum: 37.207ms 99% C.I. 7us-2322.499us Avg: 54.316us Max: 3826us
(Paused)GrayAllNewlyDirtyImmuneObjects: Sum: 23.859ms 99% C.I. 11us-98.917us Avg: 34.830us Max: 128us
FreeList:       Sum: 20.376ms 99% C.I. 2us-188.875us Avg: 29.573us Max: 998us
MarkZygoteLargeObjects: Sum: 18.970ms 99% C.I. 4us-115.749us Avg: 27.693us Max: 122us
(Paused)SetFromSpace:   Sum: 12.331ms 99% C.I. 3us-94.226us Avg: 18.001us Max: 109us
SwapBitmaps:    Sum: 11.761ms 99% C.I. 5us-49.968us Avg: 17.169us Max: 67us
ResetStack:     Sum: 4.317ms 99% C.I. 1us-64.374us Avg: 6.302us Max: 190us
UnBindBitmaps:  Sum: 3.803ms 99% C.I. 4us-49.822us Avg: 5.551us Max: 70us
(Paused)ClearCards:     Sum: 3.336ms 99% C.I. 250ns-7000ns Avg: 347ns Max: 7000ns
(Paused)FlipCallback:   Sum: 3.082ms 99% C.I. 1us-30us Avg: 4.499us Max: 30us
Done Dumping histograms
young concurrent copying paused:        Sum: 229.314ms 99% C.I. 37us-2287.499us Avg: 334.764us Max: 6850us
young concurrent copying freed-bytes: Avg: 44MB Max: 50MB Min: 9132KB
Freed-bytes histogram: 5120:1,15360:1,20480:6,25600:1,30720:1,35840:9,40960:235,46080:427,51200:4
young concurrent copying total time: 100.823s mean time: 147.187ms
young concurrent copying freed: 519927309 objects with total size 30GB
young concurrent copying throughput: 5.15683e+06/s / 304MB/s  per cpu-time: 333152554/s / 317MB/s
Average minor GC reclaim bytes ratio 0.52381 over 685 GC cycles
Average minor GC copied live bytes ratio 0.0512109 over 685 minor GCs
Cumulative bytes moved 1542000944
Cumulative objects moved 28393168
Peak regions allocated 376 (94MB) / 2048 (512MB)
Total time spent in GC: 670.771s
Mean GC size throughput: 159MB/s per cpu-time: 177MB/s
Mean GC object throughput: 2.94152e+06 objects/s
Total number of allocations 1974199562
Total bytes allocated 104GB
Total bytes freed 104GB
Free memory 10MB
Free memory until GC 10MB
Free memory until OOME 442MB
Total memory 80MB
Max memory 512MB
Zygote space size 2780KB
Total mutator paused time: 544.563ms
Total time waiting for GC to complete: 117.494ms
Total GC count: 2880
Total GC time: 670.771s
Total blocking GC count: 1
Total blocking GC time: 86.373ms
Histogram of GC count per 10000 ms: 0:259879,1:2828,2:24,3:1
Histogram of blocking GC count per 10000 ms: 0:262731,1:1
Native bytes total: 30599192 registered: 8947416
Total native bytes at last GC: 30344912

Tools zur Analyse von GC-Richtigkeitsproblemen

Es gibt verschiedene Gründe, warum ART-Inhalte zu Abstürzen führen können. Abstürze, die Lesen oder Schreiben in Objektfeldern kann auf eine Beschädigung des Heaps hinweisen. Wenn die GC stürzt ab, wenn es ausgeführt wird. Es könnte auch auf Heap-Beschädigungen hindeuten. Die häufigste Ursache für Heap-Beschädigungen ist falscher App-Code. Zum Glück gibt es Tools, Debuggen von GC und Heap-bezogenen Abstürzen, einschließlich der angegebenen Optionen für die Heap-Überprüfung und CheckJNI.

Logo: CheckJNI

CheckJNI ist ein Modus, der JNI-Prüfungen hinzufügt, um das Anwendungsverhalten zu überprüfen. werden diese nicht durch aus Leistungsgründen standardmäßig aktiviert. Dabei werden verschiedene Fehler erkannt, die zu Heap-Beschädigungen führen können, z. B. durch die Verwendung ungültiger/veralteter lokaler und globaler Referenzen. So aktivieren Sie CheckJNI:

adb shell setprop dalvik.vm.checkjni true

Der Forcecopy-Modus von CheckJNI dient dazu, Schreibvorgänge über das Ende von Array-Regionen hinaus. Wenn diese Option aktiviert ist, bewirkt „forcecopy“, dass das Array auf JNI-Funktionen zugreifen, um Kopien mit roten Zonen zurückzugeben. Ein Rotes Zone ist eine Region am Ende/Anfang des zurückgegebenen Zeigers mit dem Wert Spezieller Wert, der überprüft wird, wenn das Array freigegeben wird. Wenn die Werte in wenn der rote Bereich nicht erwartungsgemäß entspricht, oder Unterschreitung aufgetreten ist. Dadurch wird CheckJNI abgebrochen. Zum Aktivieren forcecopy-Modus:

adb shell setprop dalvik.vm.jniopts forcecopy

Ein Beispiel für einen Fehler, den CheckJNI abfangen sollte, ist ein Schreibfehler, der über das Ende Ein aus GetPrimitiveArrayCritical abgerufenes Array. Dieser Vorgang kann den Java-Heap beschädigen. Wenn der Schreibvorgang sich innerhalb der roten CheckJNI-Zone befindet, erkennt CheckJNI das Problem, wird die entsprechende ReleasePrimitiveArrayCritical aufgerufen. Andernfalls der Schreibvorgang verfälscht ein beliebiges Objekt in den Java-Heap und kann einen zukünftigen GC-Absturz verursachen. Wenn der beschädigte Speicher ist ein Referenzfeld, kann die GC den Fehler abfangen und den Fehler Tried to Markierung <ptr> dürfen nicht in Leerzeichen enthalten sein.

Dieser Fehler tritt auf, wenn bei der automatischen Speicherbereinigung versucht wird, ein Objekt zu markieren, das nicht einen Platz finden. Wenn diese Prüfung fehlschlägt, durchläuft die automatische Speicherbereinigung die Wurzeln und versucht, ob das ungültige Objekt ein Stamm ist. Nun haben Sie zwei Möglichkeiten: Das Objekt ist ein Stammobjekt oder ein Nicht-Stammobjekt.

Ungültiges Stammbeispiel

Falls das Objekt ein ungültiger Stamm ist, wird nützliche Informationen: art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:383] Tried to mark 0x2 not contained by any spaces

art E  5955  5955 art/runtime/gc/collector/mark_sweep.cc:384] Attempting see if
it's a bad root
art E  5955  5955 art/runtime/gc/collector/mark_sweep.cc:485] Found invalid
root: 0x2
art E  5955  5955 art/runtime/gc/collector/mark_sweep.cc:486]
Type=RootJavaFrame thread_id=1 location=Visiting method 'java.lang.Object
com.google.gwt.collections.JavaReadableJsArray.get(int)' at dex PC 0x0002
(native PC 0xf19609d9) vreg=1

In diesem Fall entspricht vreg=1 innerhalb von com.google.gwt.collections.JavaReadableJsArray.get ist eine Heap-Referenz enthalten, aber einen ungültigen Zeiger der Adresse 0x2. Dies ist ein ungültiger Stamm. Bis Beheben Sie dieses Problem, verwenden Sie oatdump für die Oat-Datei und suchen Sie an die Methode mit dem ungültigen Stamm an. In diesem Fall stellte sich der Fehler ein Compiler-Fehler im x86-Back-End sein. Hier finden Sie die Liste, in der das Problem behoben wurde: https://android-review.googlesource.com/#/c/133932/

Beispiel für ein beschädigtes Objekt

Wenn das Objekt kein Stamm ist, sieht die Ausgabe in etwa so aus: Drucke:

01-15 12:38:00.196  1217  1238 E art     : Attempting see if it's a bad root
01-15 12:38:00.196  1217  1238 F art     :
art/runtime/gc/collector/mark_sweep.cc:381] Can't mark invalid object

Wenn die Heap-Beschädigung kein ungültiger Stamm ist, ist die Fehlerbehebung schwierig. Diese Fehlermeldung gibt an, dass sich mindestens ein Objekt im Heap befindet der auf das ungültige Objekt verweist.