Debugowanie czyszczenia pamięci przez ART

Na tej stronie opisano, jak debugować problemy z poprawnością i wydajnością mechanizmu zbierania elementów nieużywanych (GC) w Android Runtime (ART). Z tego artykułu dowiesz się, jak korzystać z opcji weryfikacji GC, znajdować rozwiązania problemów z weryfikacją GC oraz mierzyć i rozwiązywać problemy z wydajnością GC.

Informacje o obsługiwaniu ART znajdziesz w tej sekcji ART i Dalvik oraz w artykule Format pliku wykonywalnego Dalvik. Więcej informacji o weryfikowaniu zachowania aplikacji znajdziesz w artykule Weryfikowanie zachowania aplikacji w czasie wykonywania Androida (ART).

Omówienie GC ART

ART ma kilka różnych planów GC, które składają się z różnych zbieraczy. Od Androida 8 (Oreo) domyślnym planem jest jednoczesne kopiowanie (CC). Drugim planem GC jest równoległe czyszczenie znaczników (CMS).

Oto niektóre z głównych cech GC z jednoczesnym kopiowaniem:

  • CC umożliwia korzystanie z algorytmu alokacji bump-pointer o nazwie RegionTLAB. Dzięki temu każdemu wątkowi aplikacji przydziela się lokalny bufor alokacji (TLAB), który może następnie przydzielać obiekty z TLAB, przesuwając wskaźnik „top” bez żadnej synchronizacji.
  • CC przeprowadza defragmentację stosu, kopiując jednocześnie obiekty bez wstrzymywania wątków aplikacji. Jest to możliwe dzięki zaporze odczytu, która przechwytuje odczyty referencyjne z kopca bez konieczności interwencji ze strony dewelopera aplikacji.
  • GC ma tylko jedną krótką przerwę, która jest stała w czasie w zależności od rozmiaru stosu.
  • CC staje się GC pokoleniowym w Androidzie 10 i nowszych wersjach. Umożliwia zbieranie informacji o młodych obiektach, które często dość szybko stają się niedostępne. Pomaga to zwiększyć przepustowość GC i znacznie opóźnić konieczność wykonania pełnego GC stosu.

Drugim GC, który jest nadal obsługiwany przez ART, jest CMS. Ten GC obsługuje również kompresję, ale nie równolegle. Kompakcji unikamy do momentu, gdy aplikacja przejdzie do trybu w tle. Wtedy wątki aplikacji są wstrzymywane, aby wykonać kompresję. Kompaktowość jest też niezbędna, gdy alokacja obiektu nie powiedzie się z powodu fragmentacji. W takim przypadku aplikacja może przez jakiś czas przestać reagować.

Ponieważ CMS rzadko się kompresuje, a wolne obiekty mogą nie być ciągłe, używa alokatora opartego na liście wolnych adresów o nazwie RosAlloc. Ma wyższy koszt alokacji w porównaniu z RegionTLAB. Wreszcie, ze względu na wewnętrzną fragmentację wykorzystanie pamięci stosu Java może być wyższe w przypadku CMS niż CC.

Opcje weryfikacji i wydajności GC

Zmiana typu GC

Producenci OEM mogą zmienić typ GC. Proces zmiany obejmuje ustawienie zmiennej środowiskowej ART_USE_READ_BARRIER w momencie kompilacji. Wartość domyślna to prawda, która włącza zbieracz CC, ponieważ używa on funkcji read-barrier. W przypadku CMS ta zmienna powinna być ustawiona na „false”.

Domyślnie zbieracz CC działa w trybie generacyjnym w Androidzie 10 lub nowszym. Aby wyłączyć tryb generacji, możesz użyć argumentu wiersza poleceń -Xgc:nogenerational_cc. Właściwość systemową można też ustawić w ten sposób: 

adb shell setprop dalvik.vm.gctype nogenerational_cc
 Zbieracz CMS działa zawsze w trybie generacyjnym.

Sprawdzanie stosu

Weryfikacja stosu jest prawdopodobnie najbardziej przydatną opcją GC do debugowania błędów związanych z GC lub uszkodzeniem stosu. Włączenie weryfikacji stosu powoduje, że GC sprawdza poprawność stosu w kilku punktach podczas procesu zbierania. Weryfikacja stosu ma te same opcje co opcje, które zmieniają typ GC. Jeśli jest włączona, weryfikacja stosu sprawdza korzenie i zapewnia, że dostępne obiekty odwołują się tylko do innych dostępnych obiektów. Weryfikacja GC jest włączana 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 weryfikuje stos przed rozpoczęciem procesu zamiatania przez zbieracza pamięci.
  • Jeśli ta opcja jest włączona, [no]postverify przeprowadza weryfikację stosu po zakończeniu czyszczenia przez GC.
  • [no]preverify_rosalloc, [no]postsweepingverify_rosalloc i [no]postverify_rosalloc to dodatkowe opcje GC, które weryfikują tylko stan księgowości wewnętrznej RosAlloc. Dlatego są one dostępne tylko w przypadku kolektora CMS, który korzysta z alokatora RosAlloc. Główne kwestie, które są weryfikowane, to: czy magiczne wartości są zgodne z oczekiwanymi stałymi, oraz czy wszystkie wolne bloki pamięci są zarejestrowane w mapie free_page_runs_.

Wydajność

Do pomiaru wydajności GC służą 2 główne narzędzia: zrzuty pamięci GC i Systrace. Istnieje też zaawansowana wersja Systrace, która nosi nazwę Perfetto. Wizualnym sposobem na pomiar problemów z wydajnością GC jest użycie narzędzia Systrace i Peretto w celu określenia, które GC powodują długie przerwy lub wymuszają wstrzymywanie wątków aplikacji. Mimo że GC w ART znacznie się poprawił, niewłaściwe działanie modyfikatora, np. nadmierne przydzielanie, może nadal powodować problemy z wydajnością.

Strategia windykacji

GC CC zbiera dane, wykonując młody GC lub pełny GC stosu. W idealnej sytuacji młody GC jest uruchamiany częściej. GC wykonuje zbiory CC z młodych obiektów, dopóki przepustowość (obliczona jako liczba bajtów zwolnionych na sekundę w czasie działania GC) właśnie zakończonego cyklu zbioru nie jest mniejsza niż średnia przepustowość zbiorów CC z pełnego stosu. W takiej sytuacji do następnego równoległego usuwania zbiorczego zostanie wybrany CC pełnego stosu zamiast młodego CC. Po zakończeniu pełnego zbioru stosu następny zbiór GC wraca do młodego zbioru CC. Jednym z kluczowych czynników, dzięki któremu ta strategia działa, jest to, że młody proces CC nie dostosowuje limitu śladu stosu po zakończeniu. Powoduje to, że młode CC występują coraz częściej, aż przepustowość spadnie poniżej CC pełnego stosu, co spowoduje jego zwiększenie.

Uzyskiwanie informacji o wydajności GC za pomocą polecenia SIGQUIT

Aby uzyskać informacje o czasie wykonywania GC w przypadku aplikacji, prześlij SIGQUIT do działających już aplikacji lub prześlij -XX:DumpGCPerformanceOnShutdown do dalvikvm podczas uruchamiania programu w wierszu poleceń. Gdy aplikacja otrzyma sygnał żądania ANR (SIGQUIT), wypisuje informacje dotyczące blokad, stosów wątków i wydajności GC.

Aby uzyskać zrzuty danych o czasie GC, użyj:

adb shell kill -s QUIT PID

Spowoduje to utworzenie w /data/anr/ pliku (z datą i godzinami w nazwie, np. anr_2020-07-13-19-23-39-817). Ten plik zawiera niektóre zrzuty ANR oraz czasy GC. Czasy GC możesz znaleźć, wyszukując Zbiór kumulowanych czasów GC. Te informacje o czasie pokazują kilka interesujących rzeczy, w tym informacje o histogramie dotyczące faz i przerwów poszczególnych typów GC. Zazwyczaj ważniejsze są przerwy. Przykład:

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

Wynika z tego, że średnia przerwa wynosiła 1,83 ms, co powinno być wystarczająco niskim wynikiem, aby nie powodować pomijania klatek w większości aplikacji.Nie powinno to stanowić problemu.

Innym obszarem zainteresowania jest czas zawieszenia, który mierzy, ile czasu zajmuje wątkowi dotarcie do punktu zawieszenia po wysłaniu przez GC żądania zawieszenia. Ten czas jest uwzględniany w czasie pauzy GC, więc warto wiedzieć, czy długie przerwy są spowodowane powolnym działaniem GC czy wątku. Oto przykład normalnego czasu zawieszenia na Nexusie 5:

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

Istnieją też inne obszary zainteresowania, w tym łączny czas spędzony w grze i przepustowość procesora graficznego. 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 wygenerowania danych o czasie GC w działającej już aplikacji: 

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

W tym momencie czasy GC są zawarte w anr_2020-07-13-19-23-39-817. Oto przykładowy wynik 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

ART może się zawieszać z różnych powodów. Awarie występujące podczas odczytu lub zapisu pól obiektu mogą wskazywać na uszkodzenie stosu. Jeśli podczas działania GC ulega awarii, może to również wskazywać na uszkodzenie stosu. Najczęstszą przyczyną uszkodzenia stosu jest nieprawidłowy kod aplikacji. Na szczęście istnieją narzędzia do debugowania GC i awarii związanych z kupą, w tym opcje weryfikacji kupy wymienione powyżej i CheckJNI.

CheckJNI

CheckJNI to tryb, który dodaje kontrole JNI w celu weryfikacji działania aplikacji. Z powodu wydajności nie są one domyślnie włączone. Te kontrole wykrywają kilka błędów, które mogą spowodować uszkodzenie stosu, na przykład użycie nieprawidłowych lub nieaktualnych odwołań lokalnych i globalnych. Aby włączyć CheckJNI:

adb shell setprop dalvik.vm.checkjni true

Tryb kopiowania wymuszonego w CheckJNI jest przydatny do wykrywania zapisów poza końcem regionów tablicy. Gdy ta opcja jest włączona, funkcje JNI dostępu do tablicy zwracają kopie z czerwonymi strefami. Czerwony obszar to region na końcu lub na początku zwracanego wskaźnika, który ma wartość specjalną. Jest on weryfikowany podczas uwalniania tablicy. Jeśli wartości w czerwonej strefie nie są zgodne z oczekiwaniami, wystąpiło przepełnienie lub niedopełnienie bufora. Spowoduje to przerwanie działania CheckJNI. Aby włączyć tryb kopiowania na siłę:

adb shell setprop dalvik.vm.jniopts forcecopy

Przykładem błędu, który powinien wykryć CheckJNI, jest zapisywanie poza końcem tablicy uzyskanej z GetPrimitiveArrayCritical. Ta operacja może uszkodzić stos Java. Jeśli zapis znajduje się w strefie czerwonej CheckJNI, to CheckJNI wykrywa problem, gdy wywoływana jest odpowiednia funkcja ReleasePrimitiveArrayCritical. W przeciwnym razie zapis powoduje uszkodzenie losowego obiektu w pamiętniku Java i może spowodować późniejszy błąd GC. Jeśli uszkodzona pamięć jest polem referencyjnym, GC może wykryć błąd i wydrukować komunikat Próba oznaczenia <ptr> nie zawiera żadnych spacji.

Ten błąd występuje, gdy GC próbuje oznaczyć obiekt, dla którego nie może znaleźć miejsca. Gdy to sprawdzenie się nie powiedzie, GC przejdzie przez korzenie i spróbuje sprawdzić, czy nieprawidłowy obiekt jest korzeniem. Tutaj masz 2 opcje: Obiekt jest obiektem głównym lub niegłównym.

Przykład nieprawidłowego elementu .

Jeśli obiekt jest nieprawidłowym elementem katalogu głównego, wypisuje 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 zmienna vreg=1 w strukturze com.google.gwt.collections.JavaReadableJsArray.get powinna zawierać odwołanie do stosu, ale zawiera nieprawidłowy wskaźnik do adresu 0x2. To nieprawidłowy rdzeń. Aby debugować ten problem, użyj polecenia oatdump w pliku oat i sprawdź metodę z nieprawidłowym korzeniem. W tym przypadku okazało się, że błąd był związany z kompilatorem w backendzie x86. Oto lista zmian, które rozwiązały problem: https://android-review.googlesource.com/#/c/133932/

Przykład uszkodzonego obiektu

Jeśli obiekt nie jest obiektem rdzennym, wyświetli się komunikat podobny do tych:

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

Gdy uszkodzenie stosu nie jest spowodowane nieprawidłowym źródłem, trudno jest debugować. Ten komunikat o błędzie wskazuje, że w strukturze stosu znajdował się co najmniej 1 element, który wskazywał na nieprawidłowy obiekt.