Debugowanie czyszczenia pamięci ART

Na tej stronie dowiesz się, jak debugować proces czyszczenia pamięci środowiska wykonawczego Android (ART) Problemy z poprawnością i wydajnością. Wyjaśniono, jak korzystać z weryfikacji GC rozwiązań, identyfikacji problemów związanych z błędami weryfikacji GC oraz rozwiązywać problemy z wydajnością GC.

Aby współpracować z ART, przejrzyj strony w tej ART i Dalvik oraz format wykonywalny Dalvik. Więcej informacji o weryfikowaniu działania aplikacji znajdziesz w artykule Weryfikuję działania aplikacji w środowisku wykonawczym Androida (ART).

Omówienie ART GC

ART ma kilka różnych abonamentów GC, które obejmują uruchamianie kolektory. Od Androida 8 (Oreo) domyślny abonament to jednoczesne kopiowanie (CC). Drugi abonament GC to Concurrent Mark Sweep (CMS).

Oto niektóre z najważniejszych cech przedstawionych w grze równoległego kopiowania GC:

• DW umożliwia korzystanie z funkcji przydzielania wskaźnika bump-point o nazwie RegionTLAB. Powoduje to przydzielenie wątku lokalnego bufor alokacji (TLAB) do każdego wątku aplikacji, który może następnie przydzielać obiekty z jego TLAB przejeżdżając górną krawędzią, bez synchronizacji.
• CC wykonuje defragmentację stosu przez jednoczesne kopiowanie obiektów bez wstrzymywania wątków aplikacji. Jest to możliwe dzięki barierze odczytu, która przechwytuje odczyty referencyjne z bez interwencji dewelopera aplikacji.
• GC ma tylko 1 małą przerwę, która jest stała w czasie pod względem rozmiaru sterty.
• W Androidzie 10 i nowszych CC rozszerza się jako pokoleniowe oprogramowanie GC. Umożliwia zbieranie które często stają się nieosiągalne przy niewielkim wysiłku. To pomaga zwiększając przepustowość GC i znacznie opóźniając konieczność wykonywania GC całej zawartości.

Kolejnym systemem GC, który nadal jest obsługiwany przez ART, jest CMS. Ten GC obsługuje też kompresowanie, ale nie jednocześnie. Kompaktowanie będzie unikać do czasu, aż aplikacja przechodzi w tle, dzięki czemu wątki aplikacji są wstrzymywane na potrzeby kompresowania. Kompaktowanie jest też konieczne, gdy przydział obiektu się nie uda z powodu fragmentacji. W tym gdy aplikacja może przez jakiś czas przestać odpowiadać.

Ponieważ CMS rzadko kompaktuje, więc wolne obiekty mogą nie przylegać do siebie, dlatego w funkcji bezpłatne narzędzie do udostępniania o nazwie RosAlloc. Ma wyższy koszt alokacji niż do RegionuTLAB. Ze względu na wewnętrzną fragmentację wykorzystanie pamięci przez stertę Javy może być wyższy w przypadku CMS niż CC.

Opcje weryfikacji i wydajności GC

Zmienianie typu GC

OEM może zmienić typ GC. Proces zmiany wymaga ustawienia zmiennej środowiskowej ART_USE_READ_BARRIER podczas kompilacji. Wartość domyślna to true (prawda), co włącza kolektor CC, gdy używa bariery odczytu. W systemie CMS powinna być wyraźnie ustawiona na „false”.

Domyślnie kolektor CC działa w trybie generowania w Androidzie 10 i nowszych wersjach. Do wyłącz tryb generowania, argumentem wiersza poleceń -Xgc:nogenerational_cc może być . Właściwość systemową można też ustawić w ten sposób:

adb shell setprop dalvik.vm.gctype nogenerational_cc

Kolektor CMS zawsze działa w trybie pokolenia.

Zweryfikuj stertę

Weryfikacja sterty to prawdopodobnie najbardziej przydatna opcja GC do debugowania Błędy związane z GC lub uszkodzenie stosu. Włączenie weryfikacji stosu powoduje, że GC by sprawdzić poprawność stosu w kilku punktach podczas czyszczenia procesu gromadzenia danych. Weryfikacja sterty udostępnia te same opcje co te, które zmienić typ GC. Jeśli ta opcja jest włączona, weryfikacja sterty weryfikuje korzenie główne i zapewnia, że osiągalne obiekty odwołują się tylko do innych osiągalnych obiektów. czyszczenie pamięci Weryfikacja jest włączona przez przekazanie tych wartości -Xgc:

• Jeśli ta opcja jest włączona, [no]preverify przeprowadza weryfikację stosu przed uruchomieniem GC.
• Jeśli ta opcja jest włączona, [no]presweepingverify przeprowadza weryfikację sterty przed rozpoczęciem procesu czyszczenia śmieci.
• Jeśli ta opcja jest włączona, [no]postverify przeprowadza weryfikację sterty po czyszczenie pamięci masowej zakończy się.
• [no]preverify_rosalloc, [no]postsweepingverify_rosalloc i [no]postverify_rosalloc to dodatkowe opcje GC, które weryfikują tylko stan wewnętrznej księgowości RosAlloc. Mają one zastosowanie tylko w przypadku kolektor CMS, który korzysta z alokatora RosAlloc. Główne weryfikowane dane to: że magiczne wartości pasują do oczekiwanych stałych, a wolne bloki pamięci są zarejestrowany na mapie free_page_runs_.

Wydajność

Istnieją 2 główne narzędzia do pomiaru wydajności GC: czas GC i „Systrace”. Istnieje również zaawansowana wersja Systrace o nazwie Perfetto. Wizualny sposób pomiaru problemów z wydajnością GC jest użycie narzędzi Systrace i Perfetto do określenia, które GC generują długie przerwy lub i wywłaszczanie wątków w aplikacji. Chociaż z biegiem czasu gra ART GC znacznie się doskonali, nieprawidłowy mutator takie jak nadmierna alokacja reklam mogą nadal powodować problemy ze skutecznością.

Strategia dotycząca kolekcji

Napisy tworzone na licencji są gromadzone przez uruchomienie młodej zawartości GC lub przez całą zawartość konta. Najlepiej młody GC jest uruchamiana częściej. GC tworzy zbiory młodzieżowych plików danych do momentu uzyskania przepustowości (obliczanej według bajtów) zwolnionych/sekundę czasu trwania GC) w ostatnim cyklu zbierania danych jest mniejsza niż średnia przepustowość całe sterty kolekcji CC. W takim przypadku na równoczesne treści GC, a nie młode napisy. Po zgromadzeniu całej sterty GC jest z powrotem przełączane na młode napisy. Kluczowym czynnikiem decydującym o skuteczności tej strategii jest to, że młodzi klienci nie dostosowuje limitu ilości na stercie po jego zakończeniu. Sprawia to, że młode napisy pojawiają się częściej częściej, aż przepustowość będzie mniejsza niż na pełnej stercie, co kończy się rosnącą stertą.

Używanie SIGQUIT do uzyskiwania informacji o wydajności GC

Aby uzyskać informacje o czasach działania GC dla aplikacji, wyślij SIGQUIT do już działające aplikacje lub muszą przejść -XX:DumpGCPerformanceOnShutdown na dalvikvm podczas uruchamiania programu wiersza poleceń. Gdy aplikacja sygnału żądania ANR (SIGQUIT), zrzuca informacje związane z blokadami. stosy wątków i wydajność GC.

Aby pobrać zrzuty czasu GC, użyj:

adb shell kill -s QUIT PID

Spowoduje to utworzenie pliku (z datą i godziną w nazwie, np. anr_2020-07-13-19-23-39-817). w usłudze /data/anr/. Ten zawiera zrzuty ANR i sygnały czasowe GC. Sekcja czasy GC, wyszukując Dumping Łączne czasy Gc. Te harmonogramy i pokazać kilka rzeczy, które mogą Cię zainteresować, w tym histogram na temat fazy i pauzy każdego typu GC. Pauzy są zwykle ważniejsze, godz. Na przykład:

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

Pokazuje to, że średnia przerwa wyniosła 1,83 ms, co powinno być na tyle krótkie, że W większości aplikacji nie powoduje to utraty klatek i nie powinno być problemem.

Innym obszarem zainteresowania jest czas zawieszenia, ile czasu potrzeba, aby wątek dotarł do punktu zawieszenia po wysłaniu żądania GC. zawiesza się działanie. Ten czas jest uwzględniany w przerwach GC, warto więc określ, czy długie przerwy są spowodowane powolnym działaniem GC czy wątku powolne zawieszenie. Oto przykład standardowego czasu zawieszenia na Nexusie 5:

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

Rozważamy też inne obszary zainteresowań, takie jak łączny czas spędzony na stronie czy generowanie przychodu i przepustowości. Przykłady:

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

Oto przykład zrzutu czasu GC istniejącej aplikacji:

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

W tym momencie czasy GC znajdują się w obrębie anr_2020-07-13-19-23-39-817. Oto przykładowe dane wyjściowe z Map Google:

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

Narzędzia do analizowania problemów z poprawnością GC

Awarie w ART mogą powodować różne przyczyny. Awarie, które odczyty lub zapisy w polach obiektów mogą wskazywać na uszkodzenie stosu. Jeśli Awaria GC podczas uruchamiania może wskazywać na uszkodzenie stosu. Najczęstszą przyczyną uszkodzenia stosu jest nieprawidłowy kod aplikacji. Na szczęście istnieją narzędzia, debugowanie GC i awarii związanych ze stertą, w tym określone opcje weryfikacji stosu; powyżej oraz CheckJNI.

Sprawdzanie JNI

CheckJNI to tryb, który dodaje testy JNI w celu weryfikacji działania aplikacji. nie są włączone przez: Domyślna ze względu na wydajność. Testy wykrywają kilka błędów, które mogą spowodować uszkodzenie stosu, np. za pomocą nieprawidłowych lub nieaktualnych odwołań lokalnych i globalnych. Aby włączyć CheckJNI:

adb shell setprop dalvik.vm.checkjni true

Tryb wymuszania w CheckJNI jest przydatny do wykrywania zapisuje po końcu regionów tablicy. Gdy ta opcja jest włączona, wymuszanie powoduje, że tablica uzyskać dostęp do funkcji JNI, aby zwracać kopie z czerwonymi strefami. A czerwony strefa to region na końcu/na początku zwróconego wskaźnika z atrybutem wartość specjalną, która jest weryfikowana po wydaniu tablicy. Jeśli wartości w argumencie czerwona strefa nie spełnia oczekiwanego stanu, czyli przepełnienie bufora lub zbyt małe natężenie ruchu. Powoduje to przerwanie procesu CheckJNI. Aby włączyć tryb wymuszania kopiowania:

adb shell setprop dalvik.vm.jniopts forcecopy

Przykładowy błąd, który powinien wychwytywać CheckJNI, to zapisywanie po zakończeniu tablica uzyskana z funkcji GetPrimitiveArrayCritical. Ta operacja może uszkodzić stertę Javy. Jeśli zapis to w obszarze czerwonej strefy CheckJNI, a następnie CheckJNI wykryje problem, gdy jest wywoływana odpowiednia funkcja ReleasePrimitiveArrayCritical. W przeciwnym razie zapis uszkodzi jakiś losowy obiekt w w stercie Java i może w przyszłości spowodować awarię GC. Jeśli uszkodzona pamięć jest polem referencyjnym, wtedy serwer GC może wychwytywać błąd i wyświetlić go. Podjęto próbę zaznacz <ptr> nie są zawarte w spacjach.

Ten błąd występuje, gdy GC próbuje oznaczyć obiekt, którego nie może znajdź dla nich miejsce. Jeśli wynik kontroli okaże się niezadowalający, GC będzie przechodzić przez główne katalogi i podejmować próby sprawdź, czy nieprawidłowy obiekt jest pierwiastkiem. Dostępne są 2 opcje: Obiekt jest obiektem głównym lub innym niż root.

Przykład nieprawidłowego elementu podstawowego

W przypadku, gdy obiekt ma nieprawidłowy pierwiastek, wydrukowany jest fragment przydatne informacje: 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

W tym przypadku vreg=1 w argumencie com.google.gwt.collections.JavaReadableJsArray.get to powinna zawierać odwołanie do stosu, ale zawiera nieprawidłowy wskaźnik adresu 0x2. To jest nieprawidłowy katalog główny. Do Zdebuguj ten problem, użyj polecenia oatdump w pliku Oat i sprawdź, w metodzie z nieprawidłowym pierwiaskiem. W tym przypadku błąd okazał się być błędem kompilatora w backendzie x86. Oto lista zmian, która go rozwiązała: https://android-review.googlesource.com/#/c/133932/

Przykład uszkodzonego obiektu

Jeśli obiekt nie jest rdzeniem głównym, dane wyjściowe będą podobne do tych poniżej odbitki:

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

Jeśli uszkodzenie stosu nie jest nieprawidłowym elementem głównym, trudno jest je debugować. Ten komunikat o błędzie oznacza, że na stercie był co najmniej jeden obiekt wskazujący nieprawidłowy obiekt.