Czytałem inne posty na temat śledzenia przyczyn uzyskania SIGSEGV
aplikacji na Androida. Planuję przeszukać moją aplikację pod kątem możliwych NullPointers związanych z użyciem Canvas, ale moje SIGSEGV
barfs za każdym razem wyszukują inny adres pamięci. Plus widziałem code=1
i code=2
. Gdyby to był adres pamięci 0x00000000
, miałbym wskazówkę, że to NullPointer.
Ostatni, który dostałem to code=2
:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Wszelkie sugestie, jak to wyśledzić?
Mam podejrzanego, ale jeszcze nie chcę z nim eksperymentować. Moja aplikacja korzysta z OSMDroid API do mapowania offline. Klasa OverlayItem reprezentuje znaczniki / węzły na mapie. Mam usługę, która zbiera dane przez sieć w celu wypełnienia elementu OverlayItem, które są następnie wyświetlane na mapie. W celu uproszczenia projektu rozszerzyłem OverlayItem do własnej klasy NodeOverlayItem, która zawiera pewne dodatkowe atrybuty, których używam w działaniu interfejsu użytkownika i w usłudze. To dało mi jeden punkt informacji o produkcie dla interfejsu użytkownika i usługi. Użyłem Intentów do transmisji do działania w celu odświeżenia mapy interfejsu użytkownika, gdy coś się zmieniło. Działanie wiąże się z usługą i istnieje metoda usługi, aby uzyskać listę NodeOverlayItem. Myślę, że może to być użycie OverlayItem interfejsu API OSMDroid, a moja usługa jednocześnie aktualizuje informacje o węźle. (problem współbieżności)
Pisząc to, myślę, że to naprawdę problem. Ból głowy nie rozdziela węzła i obiektu OverlayItem od obiektu NodeOverlayItem, dlatego, że działanie będzie wymagało danych z węzła przechowywanych przez usługę. Ponadto po utworzeniu działania (onResume itp.) Obiekty OverlayItem będą musiały zostać ponownie utworzone na podstawie danych węzła utrzymywanych przez usługę podczas nieobecności działania. np. uruchamiasz aplikację, usługa zbiera dane, interfejs użytkownika wyświetla je, idziesz do strony głównej, a następnie z powrotem do aplikacji, działanie będzie musiało pobrać i ponownie utworzyć obiekty OverlayItem z najnowszych danych węzła usługi.
Wiem, że to nie są świetne ani jasne pytania. To tak, jakby wszystkie moje pytania SO były niszowe lub niejasne. Jeśli ktoś ma sugestie dotyczące interpretacji tych SIGSEGV
błędów, byłoby to bardzo mile widziane!
AKTUALIZACJA Oto najnowsza awaria zarejestrowana podczas sesji debugowania. Mam 3 z tych urządzeń używanych do testowania i nie wszystkie ulegają awarii w sposób niezawodny podczas programowania i testowania. Dodałem trochę więcej, aby można było odnotować rejestrowanie GC. Widać, że problem prawdopodobnie nie jest związany z wyczerpaniem pamięci.
03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712 >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008): r0 68f52ab4 r1 412ef268 r2 4d9c3bf4 r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008): r4 001ad8f8 r5 4d9c3bf4 r6 412ef268 r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008): r8 4d9c3c0c r9 4c479dec 10 46cf260a fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008): ip 40262a04 sp 4d9c3bc8 lr 402d01dd pc 402d0182 cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008): d0 00000001000c0102 d1 3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008): d2 403fc0000000007d d3 363737343433350a
03-03 02:02:38.914: I/DEBUG(4008): d4 49544341223a2273 d5 6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008): d6 3a223645676e6f4c d7 000000013835372d
03-03 02:02:38.914: I/DEBUG(4008): d8 0000000000000000 d9 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d10 0000000000000000 d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d12 4040000000000000 d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008): d14 0000000000000000 d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d16 3fe62e42fefa39ef d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d18 3fe62e42fee00000 d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d20 0000000000000000 d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d22 4028000000000000 d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d24 0000000000000000 d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d26 0000000000000000 d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008): d28 0000000000000000 d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d30 3ff0000000000000 d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008): scr 60000013
03-03 02:02:39.046: I/DEBUG(4008): #00 pc 0006b182 /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008): #01 pc 0006b1d8 /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008): #02 pc 0001f814 /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008): #03 pc 0001ec30 /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008): #04 pc 00058c70 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81 ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800 )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10 .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631 zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13 .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630 !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573 .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020 .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025 [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b88 408d1f90 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b8c 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b90 00000001
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b94 408d6c58 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b98 408d6fa8 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b9c 4c479dec
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba0 46cf260a /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba4 408735e7 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba8 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bac 002bf070 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb0 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb4 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb8 412ef268 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bbc 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc0 df0027ad
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc4 00000000
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bcc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd4 402d01dd /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bdc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be4 4024e817 /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation
Java.Lang.Object
. Rozwiązałem moje awarieOdpowiedzi:
Najpierw uzyskaj ślad stosu nagrobków, który będzie drukowany za każdym razem, gdy nastąpi awaria aplikacji. Coś takiego:
Następnie użyj
addr2line
narzędzia (znajdź je w łańcuchu narzędzi NDK), aby znaleźć funkcję, która ulega awarii. W tym przykładzie robiszI zobaczysz, gdzie masz problem. Oczywiście to ci nie pomoże, ponieważ jest w libc.
Możesz więc połączyć narzędzia
arm-eabi-objdump
do znalezienia ostatecznego celu.Uwierz mi, to trudne zadanie.
Tylko do aktualizacji. Wydaje mi się, że dość długo robiłem natywną kompilację Androida z drzewa całego źródła, aż do dziś uważnie czytam dokumenty NDK. Od czasu wydania NDK-r6 udostępnia narzędzie o nazwie
ndk-stack
.Poniżej znajduje się treść oficjalnych dokumentów NDK z piłką smołową NDK-r9.
Przegląd:
ndk-stack
jest prostym narzędziem, które pozwala filtrować ślady stosu, które pojawiają się na wyjściu „adb logcat” i zastępować dowolny adres w bibliotece współdzielonej odpowiednimi: wartościami.Krótko mówiąc, przetłumaczy coś w stylu:
W bardziej czytelny wynik:
Stosowanie:
Aby to zrobić, najpierw potrzebujesz katalogu zawierającego symboliczne wersje bibliotek współdzielonych aplikacji. Jeśli używasz systemu kompilacji NDK (tj.
ndk-build
), To zawsze znajdują się one pod $ PROJECT_PATH / obj / local /, gdzie oznacza ABI twojego urządzenia (tj.armeabi
Domyślnie).Możesz podać
logcat
tekst jako bezpośrednie wejście do programu, np .:Lub możesz użyć opcji -dump, aby określić logcat jako plik wejściowy, np .:
WAŻNE:
Narzędzie szuka początkowej linii zawierającej początki w danych
logcat
wyjściowych, tj. Czegoś, co wygląda następująco:Podczas kopiowania / wklejania śladów nie zapomnij o tym wierszu ze śladów,
ndk-stack
ponieważ nie będzie działał poprawnie.DO ZROBIENIA:
Przyszła wersja
ndk-stack
spróbuje automatycznie uruchomićadb logcat
i wybrać ścieżkę biblioteki. Na razie musisz wykonać te czynności ręcznie.Na razie
ndk-stack
nie obsługuje bibliotek, które nie zawierają informacji debugowania. Przydatna może być próba wykrycia najbliższego punktu wejścia funkcji do danego adresu PC (np. Jak w powyższym przykładzie libc.so).źródło
printf
. Czy mogę zobaczyć wynik tegoprintf
z bibliotek natywnych.DOBRZE! Bardzo przepraszam tych, którzy faktycznie przesłali komentarze i odpowiedzi, ale znalazłem problem. Nie sądzę, żeby to pomogło wielu innym próbującym wyśledzić swój osobisty SIGSEGV, ale mój (i to było bardzo trudne) był całkowicie z tym związany:
https://code.google.com/p/android/issues/detail?id=8709
Biblioteka libcrypto.so w moim zrzutu zlepiła mnie. Robię skrót danych pakietu MD5, próbując ustalić, czy już widziałem pakiet, i pomijam go, gdybym miał. W pewnym momencie pomyślałem, że to brzydki wątek związany ze śledzeniem tych skrótów, ale okazało się, że była to klasa java.security.MessageDigest! To nie jest bezpieczne dla wątków!
Wymieniłem go z UID, który umieszczałem w każdym pakiecie na podstawie UUID urządzenia i znacznika czasu. Od tamtej pory nie ma problemów.
Myślę, że lekcją, którą mogę przekazać tym, którzy byli w mojej sytuacji, jest to, że nawet jeśli jesteś w 100% aplikacją Java, zwróć uwagę na rodzimą bibliotekę i symbol zanotowany w zrzutu awaryjnym po wskazówki. Googling dla SIGSEGV + nazwa lib .so pójdzie o wiele dalej niż bezużyteczny kod = 1 itd. ... Następnie zastanów się, gdzie Twoja aplikacja Java może dotykać kodu natywnego, nawet jeśli nic nie robisz. Popełniłem błąd, zakładając, że jest to problem z wątkami w interfejsie Service + UI, w którym Canvas rysuje coś, co jest zerowe (najczęstszy przypadek, w którym korzystałem z Google na SIGSEGV) i zignorowałem możliwość, że mogło to być całkowicie związane z kodem, który napisałem. związane z lib .so w zrzutu awaryjnym. Oczywiście java.security użyłby natywnego komponentu w libcrypto.so dla szybkości, więc kiedy się połączyłem, przejrzałem Google na Androida + SIGSEGV + libcrypto. i znalazłem udokumentowany problem. Powodzenia!
źródło
Wystąpił ten błąd, zapisując obiekt we wspólnych preferencjach jako ciąg przekonwertowany przez gson. Ciąg gson nie był dobry, więc pobieranie i deserializowanie obiektu nie działało właściwie. Oznaczało to, że każde kolejne dostęp do obiektu spowodowało błąd. Straszny :)
źródło
android.Location
obiektu wSharedPreferences
w sposóbWakefulBroadcastReceiver
. Przez większość czasu to działa, ale czasami mam strasznąSIGSEGV
awarię. Czy możesz opowiedzieć, jak to rozwiązałeś?Ten błąd również występował wiele razy i go rozwiązałem. Ten błąd pojawi się w przypadku zarządzania pamięcią po stronie natywnej.
Twoja aplikacja uzyskuje dostęp do pamięci poza swoją przestrzenią adresową. Najprawdopodobniej jest to nieprawidłowy dostęp do wskaźnika. SIGSEGV = błąd segmentacji w kodzie natywnym. Ponieważ nie występuje w kodzie Java, nie zobaczysz śladu stosu ze szczegółami. Jednak nadal możesz zobaczyć pewne informacje śledzenia stosu w logcat, jeśli rozejrzysz się trochę po awarii procesu aplikacji. Nie powie ci numer linii w pliku, ale powie ci, które pliki obiektów i adresy były używane w łańcuchu połączeń. Stamtąd często można dowiedzieć się, który obszar kodu jest problematyczny. Możesz także skonfigurować natywne połączenie gdb z procesem docelowym i złapać je w debuggerze.
źródło
Dzisiaj stanąłem przed
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
problemem i przez pół dnia staram się go rozwiązać.Próbowałem wielu rzeczy, czyszcząc pamięć podręczną i usuwając plik .gradle i wszystko.
Wreszcie ja
disable Instant Run
i teraz nie otrzymuję tego problemu ponownie. Teraz moja aplikacja działa również po włączeniu natychmiastowego uruchomienia. Może to być problem z natychmiastowym uruchomieniem. Spróbuj wyłączyć lub włączyć natychmiastowe uruchomienieZ tej odpowiedzi:
źródło
Spróbuj wyłączyć akcelerację sprzętową Androida w swoim manifeście.
źródło
Wystąpił ten błąd, gdy próbowałem uzyskać dostęp do „obszaru roboczego” poza
onDraw()
Bardzo zła praktyka: /
źródło
Podczas używania takiej mapy bitowej pojawiał się ten błąd:
Tym, co rozwiązało problem, było zmniejszenie rozmiaru mapy bitowej (> 1000px high do 700px).
źródło
BitmapOptions.inSampleSize
Mam do czynienia z SIGSEGV na Androidzie 4.4.4 (Nexuses, Samsungs). Okazało się, że błąd krytyczny polegał na analizie
null
String
przy użyciuDecimalFormat
W Androidzie> 21 został pomyślnie obsłużony za pomocą try / catch
źródło
I wobec tej chwili kwestia temu, po migracji od
android.support
celuandroidx
.Problem polegał na tym
renderscript
.Rozwiązanie: usunąłem z
build.gradle
tych dwóch wierszy:po niepowodzeniu budowania tego projektu z powodu nierozwiązanych odniesień:
więc zmieniłem je na:
Po tym wszystkie problemy zniknęły.
źródło
Jeśli używasz biblioteki vitamio i występuje ten błąd krytyczny.
Następnie upewnij się, że w twoim projekcie cel targetSdkVersion musi być mniejszy niż 23.
dzięki.
źródło
W moim przypadku (używam formularzy Xamarin) ten błąd został zgłoszony z powodu błędu wiązania - np .:
Zasadniczo przez pomyłkę usunąłem właściwość modelu widoku. W przypadku programistów Xamarin, jeśli masz ten sam problem, sprawdź swoje powiązania ...
źródło
Jeśli dodałeś do swojego projektu natywny kod C. Ta odpowiedź może być pomocna.
Dodałem trochę natywnego kodu C w projekcie Android.
Teraz próbowałem uzyskać dostęp do kodu, który zwracał mi ciąg natywny, zanim przetworzyłem ciąg, który ustawiłem jego wartość domyślną na nullptr. Teraz po odzyskaniu jego wartości w kodzie java napotkałem ten problem.
Ponieważ nasz natywny kod C znajduje się poza katalogiem java, więc nie mamy pojęcia o dokładnej linii kodu, która jest przyczyną problemu. Proponuję więc sprawdzić plik .cpp i znaleźć tam jakąkolwiek wskazówkę.
Mam nadzieję, że wkrótce pozbędziesz się problemu. :)
źródło
W moim przypadku przyczyną problemu był Android Profiler. W Android Studio kliknij „Android Profiler” i „end session”.
Jak na ironię, powodowało to również ekstremalne problemy z wydajnością w aplikacji.
źródło
Dodaj te dwie linie do swojego build.gradle w sekcji Androida:
źródło
Sprawdź swój JNI / kod macierzysty. Jedno z moich odniesień było zerowe, ale było przerywane, więc nie było to zbyt oczywiste.
źródło
sprawdź swoje rodzime funkcje, czy zwraca poprawnie, czy nie. Jeśli nie zostanie zwrócone, dodaj instrukcje return.
źródło
Dla mnie ten problem był spowodowany złą obsadą dwóch czynności. Niedawno przeniosłem tę metodę z Ćwiczenia 1 na inną 2. W ten sposób refaktor pozostawił tę jawną obsadę taką, jaka była wcześniej. Więc zamiast robić
Miałem to zrobić
Uwaga: Ale ten błąd nie wystąpił na Androidzie 8.0 Nie jestem jeszcze pewien, dlaczego.
*** Mam nadzieję, że to pomoże.
źródło
Miałem błąd błędu segmentacji z powodu problemów z pamięcią . Moja struktura z wieloma zmiennymi i tablicami miała tablicę o rozmiarze 1024.
PS: To jest obejście, a nie rozwiązanie. Konieczne jest znalezienie rozmiaru struktury, a lepszym rozwiązaniem jest dynamiczny przydział pamięci .
źródło
Wystąpił ten błąd, gdy użyłem
onDraw()
funkcji wewnętrznej ViewTreeObserver .źródło
Miałem ten problem z pakietem, który został dodany do mojej aplikacji (FancyShowCaseView) i spowodowałem ten problem na pre-Lolipop. ten pakiet został napisany w Kotlin, a moje główne kody zostały napisane w Javie. więc teraz sprawdzam wersję w pre-Lolipopie i nie pozwalam na wykonanie jej klasy. tymczasowo rozwiązał problem. sprawdź to, jeśli masz podobny problem jak ja
źródło
2 z 12 telefonów zwróciło błąd, znaleziono problem w onDrawFrame (), niektóre obiekty były zerowe, nie wiem dlaczego, właśnie ustawiłem
if(gears==null) return;
.źródło
Wystąpił problem podczas tworzenia pliku PDF za pomocą interfejsów API PDF systemu Android i przypadkowo użyłem canvas.save () i canvas.restore () po zamknięciu strony pdf.
źródło