Na tej stronie opisano, jak debugować problemy z poprawnością i wydajnością usuwania elementów bezużytecznych (GC) środowiska uruchomieniowego systemu Android (ART). Wyjaśnia, jak korzystać z opcji weryfikacji GC, identyfikować rozwiązania błędów weryfikacji GC oraz mierzyć i rozwiązywać problemy z wydajnością GC.
Aby pracować z ART, zobacz strony w tej sekcji ART i Dalvik oraz format Dalvik Executable . Aby uzyskać dodatkową pomoc dotyczącą weryfikowania zachowania aplikacji, zobacz Weryfikowanie zachowania aplikacji w środowisku wykonawczym systemu Android (ART) .
Przegląd ART GC
ART ma kilka różnych planów GC, które obejmują uruchamianie różnych modułów zbierających elementy bezużyteczne. Począwszy od systemu Android 8 (Oreo), domyślnym planem jest kopiowanie współbieżne (CC). Drugi plan GC to Concurrent Mark Sweep (CMS).
Oto niektóre z głównych cech Concurrent Copying GC:
- CC umożliwia użycie alokatora wskaźników wypukłych o nazwie RegionTLAB. Spowoduje to przydzielenie lokalnego bufora alokacji wątku (TLAB) do każdego wątku aplikacji, który może następnie przydzielić obiekty ze swojego TLAB, uderzając w „górny” wskaźnik, bez żadnej synchronizacji.
- CC przeprowadza defragmentację sterty poprzez jednoczesne kopiowanie obiektów bez wstrzymywania wątków aplikacji. Osiąga się to za pomocą bariery odczytu, która przechwytuje odczyty referencyjne ze sterty, bez konieczności jakiejkolwiek interwencji ze strony twórcy aplikacji.
- GC ma tylko jedną małą pauzę, która jest stała w czasie w odniesieniu do rozmiaru sterty.
- CC staje się pokoleniowym GC w systemie Android 10 i nowszych wersjach. Umożliwia kolekcjonowanie młodych obiektów, które często stają się nieosiągalne dość szybko i przy niewielkim wysiłku. Pomaga to poprzez zwiększenie przepustowości GC i znacznie opóźnia potrzebę wykonania GC na pełnej stercie.
Drugim GC, który ART nadal obsługuje, jest CMS. Ten GC również obsługuje zagęszczanie, ale nie jednocześnie. Kompaktowania unika się do czasu, aż aplikacja przejdzie w tło, kiedy to wątki aplikacji zostaną wstrzymane w celu przeprowadzenia kompresji. Kompaktowanie staje się również konieczne, gdy alokacja obiektu nie powiedzie się z powodu fragmentacji. W takim przypadku aplikacja może potencjalnie przestać odpowiadać przez jakiś czas.
Ponieważ CMS rzadko kompaktuje, a zatem wolne obiekty mogą nie przylegać do siebie, używa alokatora opartego na wolnych listach o nazwie RosAlloc. Ma wyższy koszt alokacji w porównaniu do RegionTLAB. Wreszcie, z powodu wewnętrznej fragmentacji, zużycie pamięci przez stertę Java może być wyższe w przypadku CMS niż CC.
Opcje weryfikacji i wydajności GC
Zmień typ GC
Producenci OEM mogą zmienić typ GC. Proces zmiany obejmuje ustawienie zmiennej środowiskowej ART_USE_READ_BARRIER w czasie kompilacji. Wartość domyślna to true, co włącza moduł zbierający CC, ponieważ korzysta z bariery odczytu. W przypadku CMS ta zmienna powinna być jawnie ustawiona na wartość false.
Domyślnie kolektor CC działa w trybie generacyjnym w systemie Android 10 i nowszych. Aby wyłączyć tryb generacyjny, można użyć argumentu wiersza poleceń -Xgc:nogenerational_cc . Alternatywnie właściwość systemową można ustawić w następujący sposób:
adb shell setprop dalvik.vm.gctype nogenerational_ccKolektor CMS zawsze działa w trybie generacyjnym.
Sprawdź stertę
Weryfikacja sterty jest prawdopodobnie najbardziej użyteczną opcją GC do debugowania błędów związanych z GC lub uszkodzeń sterty. Włączenie weryfikacji sterty powoduje, że GC sprawdza poprawność sterty w kilku punktach podczas procesu usuwania śmieci. Weryfikacja sterty ma te same opcje, co te, które zmieniają typ GC. Jeśli jest włączona, weryfikacja sterty weryfikuje korzenie i gwarantuje, że osiągalne obiekty odwołują się tylko do innych osiągalnych obiektów. Weryfikację GC włącza się poprzez przekazanie następujących wartości -Xgc :
- Jeśli jest włączona,
[no]preverifyprzeprowadza weryfikację sterty przed uruchomieniem GC. - Jeśli jest włączona,
[no]presweepingverifyprzeprowadza weryfikację sterty przed rozpoczęciem procesu czyszczenia modułu zbierającego elementy bezużyteczne. - Jeśli ta opcja jest włączona,
[no]postverifyprzeprowadza weryfikację sterty po zakończeniu przeglądania przez GC. -
[no]preverify_rosalloc,[no]postsweepingverify_rosalloci[no]postverify_rosallocto dodatkowe opcje GC, które weryfikują jedynie stan wewnętrznej księgowości RosAlloc. Dlatego można je zastosować tylko w przypadku modułu zbierającego CMS, który korzysta z alokatora RosAlloc. Najważniejsze zweryfikowane rzeczy to to, że magiczne wartości odpowiadają oczekiwanym stałym, a wolne bloki pamięci są rejestrowane na mapiefree_page_runs_.
Wydajność
Istnieją dwa główne narzędzia do pomiaru wydajności GC, zrzuty czasu GC i Systrace. Istnieje również zaawansowana wersja Systrace o nazwie Perfetto. Wizualnym sposobem pomiaru problemów z wydajnością GC jest użycie Systrace i Perfetto do określenia, które GC powodują długie przerwy lub wywłaszczają wątki aplikacji. Chociaż z biegiem czasu ART GC znacznie się poprawiło, złe zachowanie mutatora, takie jak nadmierna alokacja, może nadal powodować problemy z wydajnością
Strategia zbierania
CC GC zbiera dane, uruchamiając młodą GC lub GC z pełną stertą. Idealnie byłoby, gdyby młody GC był uruchamiany częściej. GC wykonuje młode kolekcje CC do momentu, gdy przepustowość (obliczana jako liczba zwolnionych bajtów/sekundę czasu trwania GC) właśnie zakończonego cyklu kolekcji jest mniejsza niż średnia przepustowość kolekcji CC z pełną stertą. Kiedy to nastąpi, zamiast młodego CC wybierany jest CC z pełną stertą dla następnego współbieżnego GC. Po zakończeniu zbierania pełnej sterty następny GC jest przełączany z powrotem na młode CC. Jednym z kluczowych czynników, który sprawia, że ta strategia działa, jest to, że młody CC nie dostosowuje limitu zajmowanego sterty po jej zakończeniu. Powoduje to, że młode CC zdarza się coraz częściej, aż przepustowość jest niższa niż CC przy pełnej stercie, co kończy się wzrostem sterty.
Użyj SIGQUIT, aby uzyskać informacje o wydajności GC
Aby uzyskać czasy wydajności GC dla aplikacji, wyślij SIGQUIT do już działających aplikacji lub przekaż -XX:DumpGCPerformanceOnShutdown do dalvikvm podczas uruchamiania programu wiersza poleceń. Gdy aplikacja otrzymuje sygnał żądania ANR ( SIGQUIT ), zrzuca informacje związane z jej blokadami, stosami wątków i wydajnością GC.
Aby uzyskać 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 /data/anr/ . Ten plik zawiera zrzuty ANR oraz czasy GC. Możesz zlokalizować czasy GC, wyszukując Dumping skumulowane czasy Gc . Te czasy pokazują kilka rzeczy, które mogą być interesujące, w tym informacje o histogramie dla faz i pauz każdego typu GC. Pauzy są zazwyczaj ważniejsze, na które warto zwrócić uwagę. 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, aby nie powodować utraty klatek w większości aplikacji i nie powinno stanowić problemu.
Innym obszarem zainteresowań jest czas zawieszenia, który mierzy, ile czasu zajmuje wątkowi osiągnięcie punktu zawieszenia po zażądaniu zawieszenia przez GC. Czas ten jest wliczany do przerw w GC, warto więc określić, czy długie przerwy są spowodowane powolnym działaniem GC lub powolnym zawieszaniem 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ą inne obszary zainteresowań, w tym całkowity czas spędzony i przepustowość GC. 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, jak zrzucić czasy GC już działającej aplikacji:
adb shell kill -s QUIT PIDadb pull /data/anr/anr_2020-07-13-19-23-39-817
W tym momencie czasy GC mieszczą się w przedziale 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 analizy problemów z poprawnością GC
Różne rzeczy mogą powodować awarie wewnątrz ART. Awarie podczas odczytu lub zapisu w polach obiektu mogą wskazywać na uszkodzenie sterty. Jeśli GC ulegnie awarii podczas działania, może to również wskazywać na uszkodzenie sterty. Najczęstszą przyczyną uszkodzenia sterty jest nieprawidłowy kod aplikacji. Na szczęście istnieją narzędzia do debugowania awarii związanych z GC i stertą, w tym określone powyżej opcje weryfikacji sterty i CheckJNI.
Sprawdź JNI
CheckJNI to tryb, który dodaje kontrole JNI w celu sprawdzenia zachowania aplikacji; nie są one domyślnie włączone ze względu na wydajność. Kontrole wyłapują kilka błędów, które mogą spowodować uszkodzenie sterty, np. użycie nieprawidłowych/nieaktualnych odniesień lokalnych i globalnych. Aby włączyć CheckJNI:
adb shell setprop dalvik.vm.checkjni true
Tryb wymuszania kopiowania CheckJNI jest przydatny do wykrywania zapisów poza końcem regionów tablicy. Po włączeniu tej opcji wymuszanie kopiowania powoduje, że funkcje JNI dostępu do tablicy zwracają kopie z czerwonymi strefami. Czerwona strefa to obszar na końcu/początku zwracanego wskaźnika, który ma specjalną wartość, która jest weryfikowana po zwolnieniu tablicy. Jeśli wartości w czerwonej strefie nie odpowiadają oczekiwaniom, nastąpiło przepełnienie lub niedopełnienie bufora. Powoduje to przerwanie działania CheckJNI. Aby włączyć tryb wymuszania kopiowania:
adb shell setprop dalvik.vm.jniopts forcecopy
Przykładem błędu, który powinien wychwycić CheckJNI, jest zapis poza końcem tablicy uzyskanej z GetPrimitiveArrayCritical . Ta operacja może uszkodzić stertę Java. Jeśli zapis znajduje się w obszarze czerwonej strefy CheckJNI, CheckJNI wychwytuje problem po wywołaniu odpowiedniego ReleasePrimitiveArrayCritical . W przeciwnym razie zapis uszkadza jakiś losowy obiekt na stercie Java i może spowodować przyszłą awarię GC. Jeśli uszkodzona pamięć jest polem referencyjnym, GC może wychwycić błąd i wydrukować błąd . Próbowano oznaczyć <ptr> nie zawarty w żadnych spacjach .
Ten błąd występuje, gdy GC próbuje oznaczyć obiekt, dla którego nie może znaleźć miejsca. Gdy ta kontrola zakończy się niepowodzeniem, GC przechodzi przez korzenie i próbuje sprawdzić, czy nieprawidłowy obiekt jest korzeniem. Istnieją dwie opcje: Obiekt jest obiektem głównym lub obiektem innym niż główny.
Nieprawidłowy przykład katalogu głównego
W przypadku, gdy obiekt jest nieprawidłowym rootem, 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 vreg=1 wewnątrz com.google.gwt.collections.JavaReadableJsArray.get powinien zawierać odwołanie do sterty, ale zawiera nieprawidłowy wskaźnik adresu 0x2 . To jest nieprawidłowy katalog główny. Aby zdebugować ten problem, użyj oatdump w pliku oat i spójrz na metodę z nieprawidłowym rootem. W tym przypadku błąd okazał się błędem kompilatora w backendie x86. Oto lista zmian, która to naprawiła: https://android-review.googlesource.com/#/c/133932/
Przykład uszkodzonego obiektu
Jeśli obiekt nie jest obiektem głównym, wypisz wynik podobny do poniższego:
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 sterty nie jest nieprawidłowym katalogiem głównym, trudno jest je debugować. Ten komunikat o błędzie wskazuje, że na stercie znajdował się co najmniej jeden obiekt wskazujący nieprawidłowy obiekt.